Researchers working with MIT have found a new flaw in Apple processors that they’re calling unpatchable. While that sounds bad — and under specific circumstances, could be bad — it’s probably not something consumers need to worry about much.
The flaw, dubbed PACMAN, is caused by a hardware security problem with Apple’s pointer authentication codes (PAC). The researchers write: “We demonstrate that by leveraging speculative execution attacks, an attacker can bypass an important software security primitive called ARM Pointer Authentication to conduct a control-flow hijacking attack.” Pointers are objects in code that contain memory addresses. By modifying the data inside of pointers, an attacker can theoretically modify what happens when the machine accesses a given area of memory.
Pointer authentication protects pointers by encrypting them. While it may be possible to brute force some of the smallest pointer authentication schemes, using an incorrect pointer authentication code will crash the program. Restarting said program will generate new PACs, forcing the attacker to start the process over. Eventually, the constant crashing is going to get suspicious. Brute-forcing pointer authentication is not a practical means of extracting useful information.
What does work is exfiltrating data through side channels and taking advantage of speculative execution. The team writes:
The key insight of our PACMAN attack is to use speculative execution to stealthily leak PAC verification results via microarchitectural side channels. Our attack works relying on PACMAN gadgets. A PACMAN gadget consists of two operations: 1) a pointer verification operation that speculatively verifies the correctness of a guessed PAC, and 2) a transmission operation that speculatively transmits the verification result via a micro-architectural side channel… Note that we execute both operations on a mis-speculated path. Thus, the two operations will not trigger architecture-visible events, avoiding the issue where invalid guesses result in crashes.
PACMAN relies on a different mechanism than Spectre or Meltdown, but it’s exactly the same type of trick. While you can read our primer on speculative execution here, the concept is easy to understand. Speculative execution is what happens when a CPU executes code before it knows if that code will be useful or not. It’s a critical part of modern processors. All modern high-performance processors perform what is known as “out of order” execution. This means the chip does not execute instructions in the precise order they arrive. Instead, code is reorganized and executed in whatever arrangement the CPU front-end believes will be most efficient.
By executing code speculatively, a CPU can make certain it has results on-hand whether they are needed or not, but this flexibility can also be exploited and abused. Because speculatively-executed code isn’t meant to be kept, failing to brute-force the pointer authentication code doesn’t crash the program the same way. That’s what the researchers have done here.
End users probably don’t need to worry about this kind of problem, despite the fact that it’s being billed as unpatchable. One of the weaknesses of PACMAN is that it relies on a known bug in a pre-existing application that Pointer Authentication is protecting in the first place. PACMAN doesn’t directly create a flaw in an application where one previously did not exist — it breaks a security mechanism meant to protect already-flawed applications from being exploited.
According to Apple spokesperson Scott Radcliffe, “Based on our analysis as well as the details shared with us by the researchers, we have concluded this issue does not pose an immediate risk to our users and is insufficient to bypass operating system security protections on its own.”
In ExtremeTech’s estimation, Apple is probably correct.
Comparing PACMAN, Spectre, and Meltdown
The surface-level difference between PACMAN and problems like Spectre is that they target different aspects of a chip. PACMAN targets TLB (Translation Lookaside Buffer) side channels instead of exploiting weaknesses in how conditional branches or address mispredictions are processed. But the fact that a new research team has found a new target in a previously uninvestigated CPU speaks to the larger problem at hand. We’re four years into this exciting new era in computer security, and new problems are still cropping up on a regular basis. They’re never going to stop.
A great deal of verbiage has been devoted to Spectre, Meltdown, and the various follow-up attacks that have surfaced in the years since. The names blur together at this point. Intel was easily the hardest-hit manufacturer, but scarcely the only one. What ties all of these flaws together? They never seem to show up in actual attacks and no major malware releases by state actors, ransomware groups, or run-of-the-mill botnets are yet known to rely on them. For whatever reason, both commercial and state-affiliated hacking organizations have chosen not to focus on speculative execution attacks.
One possibility is that these attacks are too difficult to take advantage of when there are easier strategies. Another is that hackers may not want to fool with trying to identify which specific systems are vulnerable to which attacks. Now that there are multiple generations of post-Spectre AMD and Intel hardware in market, there are multiple approaches to dealing with these problems implemented in both software and hardware. Whatever the reason, the much-feared risks have not materialized.
The Annoying Gap Between Security Disclosures and Reality
Problems like those the authors document are real, just like Spectre and Meltdown were real. Documenting these flaws and understanding their real-world risks is important. Patching your system when manufacturers release fixes for these kinds of flaws is important — but it can also come with costs. In the case of speculative execution attacks like Spectre and Meltdown, customers gave up real-world performance to patch a post-launch security problem. While most consumer applications were modestly affected, some server applications took a heavy hit. It’s one thing to ask customers to take it on the chin as a one-time deal, but the steady drumbeat of security research since Spectre and Meltdown were disclosed in 2018 suggests that these disclosures aren’t going to stop.
CPU researchers keep finding these errors, everywhere they look. The researchers attached to this work noted that their project is generic enough to potentially apply to ARM chips manufactured by other companies, though this is not proven. It isn’t clear to me if any of the changes in ARMv9 will address these security issues, but Pointer Authentication is a new feature, having previously been introduced in ARMv8.3.
The reason side channel attacks are hard to fix is because they aren’t direct attacks at all. Side-channel attacks are attacks based on information gathered based on how a system is implemented rather than because of flaws in the protocol. Imagine looking at the power meters for each apartment in a building. On a hot summer day, you might be able to tell who was home and who was not based on how quickly the meter was spinning. If you used that information to pick an apartment to rob, you’d be using a real-world side channel attack to pick your target. All of the solutions to this problem involve making it harder for certain individuals to read power meter data, despite the fact that power meters are designed to be read. Any effort to make this data more secure must contend with the need to read it in the first place.
Over the last four years, we’ve seen a steady stream of hardware security problems that haven’t actually caused any problems. One reason I think these stories continue to pick up so much press is because no one, including yours truly, wants to be the Bad Security Reporter. It’s much easier to tell people to pay a lot of attention to security disclosures than it is to admit that security disclosures might not matter or be as newsworthy as initial reports suggest.
Far too many security reports now lead with reports of unpatchable flaws when the risk is lower than such phrasing would suggest. Every modern high-performance CPU uses speculative execution. All of them are vulnerable to side channel attacks, and the attention lavished on Spectre and Meltdown has inspired a wave of similar research. The flaws are real. The risks they present are sometimes overblown.