Researchers working with MIT have discovered a new flaw in the Apple processor that they call patchable. Although it sounds bad – and in certain situations, it can Stay Worse – this is probably not something that consumers have to worry about too much.
The error occurred due to a hardware security issue with the PACMAN dub, Apple’s Pointer Authentication Code (PAC). The researchers wrote: “We show that by taking advantage of a hypothetical execution attack, an attacker can bypass a primitive software security primer called ARM Pointer Authentication to conduct a control-flow hijacking attack.” Pointers are objects of code that contain memory addresses. By changing the data inside the pointers, an attacker could theoretically change what happens when the machine accesses a given area of memory.
Pointer authentication protects pointers by encrypting them. Although it is possible to force some of the smallest pointer authentication schemes, using an incorrect pointer authentication code will cause the program to crash. Restarting the said program will create a new PAC, forcing the attacker to start the process. Eventually, the constant crashing is going to get suspicious. Brute-forcing pointer authentication is not a practical way to gather useful information.
What? By The task is to extract data through side channels and take advantage of speculative performance. The team wrote:
One of the key insights of our PACMAN attack is the use of presumptive executions to secretly leak the results of PAC verification through microarchitectural side channels. Our attack works on PACMAN gadgets. A PACMAN gadget consists of two functions: 1) a pointer verification operation that verifies the accuracy of the estimated PAC and 2) a transmission operation that presumably transmits the results of the verification through a micro-architectural side channel … Remember that we both This way, two actions will not trigger architectural-visible events, avoiding the problem where incorrect guessing causes a crash.
PACMAN depends on a different process than Specter or Meltdown, but this is exactly the same strategy. You can read our primer on hypothetical performance here, the concept is easy to understand. Speculative execution that occurs when a CPU will execute the code before the code is executed. This is an important part of modern processors. Performs all modern high-performance processors known as “out of order” execution. That means chips No. Instructions in the correct order they arrive. Instead, the CPU front-end believes that reorganizing and executing the code will be most effective in any system.
By running the code hypothetically, a CPU can confirm whether it has the results it needs or not, but this flexibility can also lead to exploitation and abuse. This is because the program does not crash in the same way if the pointer fails to brute-force the authentication code, not to keep the code that is supposedly executed. That’s what researchers have done here.
End users probably don’t have to worry about this kind of problem, even though it’s being billed as patchable. One of the weaknesses of PACMAN is that it relies on a known bug in a pre-existing application that is protecting pointer authentication in the first place. PACMAN does not directly create an error in an application that does not already exist – it breaks a security measure to protect already malformed applications from being exploited.
According to Apple spokesman Scott Radcliffe, “Based on our analysis as well as the details shared with us by researchers, we conclude that this issue does not pose an immediate risk to our users and is insufficient to bypass operating system security.” “
According to ExtremeTech, Apple is probably right.
Compare PACMAN, Specter, and Meltdown
The surface-level difference between problems like PACMAN and Specter is that they target different aspects of a chip. PACMAN targets TLB (translation lookside buffer) side channels instead of exploiting the weaknesses of how conditional branch or address misconceptions are processed. But the fact that a new research team has found a new target in the previously undetected CPU speaks volumes about the larger hand problem. We’ve been through four exciting years in this exciting new age of computer security, and new issues are still cropping up regularly. They are not going to stop.
Specter, Meltdown, and various follow-up attacks published in the years that followed have been well-chosen. At this point the names become blurred together. Intel was easily the hardest-hit maker, but rarely the only one. What combines all these errors? They never appear to be in actual attack, and no major malware releases by state actors, ransomware groups, or run-of-the-mill botnets are still known to rely on them. For whatever reason, both commercial and state-affiliated hacking organizations have chosen not to focus on speculative executions.
One possibility is that it is very difficult to take advantage of these attacks when there is a simple strategy. Another is that hackers do not want to be fooled into trying to identify a particular system that is vulnerable to an attack. Now that there are multiple generations of post-spectrum AMD and Intel hardware on the market, there are multiple ways to address these issues in both software and hardware. Because whatever the reason, the risk of many fears has not been realized.
An annoying gap between security disclosure and reality
Problems like the author’s document were real, just as Specter and Meltdown were real. It is important to document these errors and understand their real-world risks It’s important to patch your system when manufacturers release solutions for these types of errors – but it can come at a cost. In the case of speculative execution attacks like Specter and Meltdown, customers leave real-world performance to patch post-launch security issues. While most consumer applications were moderately affected, some server applications were hit hard. It’s one thing to ask customers to take it on the chin as a one-time deal, but since the release of Specter and Meltdown in 2018, security research firm Drumbit suggests that these releases won’t stop.
CPU researchers tend to find these flaws, wherever they look. Researchers involved in this work have noted that their project is common enough to potentially be applied to ARM chips manufactured by other companies, although this has not been proven. It is not clear to me whether any changes to ARMv9 will fix this security issue, but pointer authentication is a new feature, previously introduced in ARMv8.3.
Side channel attacks are difficult to fix because they are not direct attacks A side-channel attack is an attack based on information collected based on how a system is implemented due to a protocol error. Imagine looking at the power meter for each apartment in a building. On a hot day, you might be able to tell who was at home and who was not based on how fast the meter was spinning. If you use this information to pick an apartment to loot, you will use a real-world side channel attack to pick your target. All of the solutions to this problem include making it difficult for certain people to read power meter data, albeit a power meter Designed for reading. Any attempt to further secure this data must first combat the need to read it.
Over the past four years, we’ve seen a steady stream of hardware security issues that haven’t actually caused any problems. I think one of the reasons these stories are picked up so much by the press is because no one really wants to be a bad security reporter, including you. It’s much easier to tell people to pay more attention to security disclosures, than to admit that security disclosures may not be as important or newsworthy as the initial report suggests.
Many more security reports now lead to reports of uncommon errors when the risk is lower than suggested by such phrases. Each modern high-performance CPU uses predictive performance. All of them are vulnerable to side channel attacks, and drawing attention to Specter and Meltdown has inspired a wave of similar research. The errors are real. The risks they present are sometimes excessive.