New 'PacMan' flaw in Apple Silicon is an echo of Spectre and Meltdown

AppleInsider

Researchers at MIT have discovered an unfixable vulnerability in Apple Silicon that could allow attackers to bypass a chip's "last line of defense" -- but most Mac users shouldn't be worried.

Apple M1 Chip

More specifically, the team at MIT's Computer Science & Artificial Intelligence Laboratory found that Apple's implementation of pointer authentication in the M1 system-on-chip can be overcome with a specific hardware attack they've dubbed "PACMAN."

Pointer authentication is a security mechanism in Apple Silicon that makes it more difficult for attackers to modify pointers in memory. By checking for unexpected changes in pointers, the mechanism can help defend a CPU if attackers gain memory access.

"The idea behind pointer authentication is that if all else has failed, you still can rely on it to prevent attackers from gaining control of your system," said Joseph Ravichandran, one of the paper's co-authors.

Apple's M1 chip was the first commercially available processor to feature ARM-based pointer authentication. However, the MIT team has discovered a method leveraging speculative execution techniques to bypass pointer authentication.

The flaw comes into play when an attacker successfully guesses the value of a pointer authentication code and disables it. The researchers found that they could use a side-channel attack to brute-force the code.

PACMAN echoes similar speculative execution attacks like Spectre and Meltdown, which also leveraged microarchitectural side channels. Because it's a flaw in the hardware, it can't be fixed with a software patch.

The PACMAN vulnerability itself can't bypass the security mechanisms on a Mac. Instead, the flaw could make other exploits or attacks more serious and expand the overall attack surface.

Who's at risk and how to protect yourself

The researchers note that no attacks currently leverage the PACMAN flaw and it isn't a "magic bypass for all security on the M1 chip." Instead, it can only take an existing bug that pointer authentication protects against and "unleash" its true potential.

The flaw affects all kinds of ARM-based chips -- not just Apple's. The vulnerability is more of a technological demonstration of a wider issue with pointer authentication in ARM chips, rather than an issue that could lead to your Mac getting hacked.

"Future CPU designers should take care to consider this attack when building the secure systems of tomorrow," said Ravichandran. "Developers should take care to not solely rely on pointer authentication to protect their software."

Read on AppleInsider

hackintoisier

Intel rightfully took a lot of flak for specter and meltdown but this just proves how difficult it is to mass produce produce high performance cpu  hardware that’s free from vulnerability or attack. 

chadbag

The flaw affects all kinds of ARM-based chips — not just Apple's. 

But right above this line it says that the M1 is the first commercially available ARM based chip that offers the feature the flaw was found in.  In the last year have other ARM chips become commercially available with this pointer protection feature?

Also, chips without the feature don't have the protection in the first place, so it stands to reason that all other ARM chips are by default equivalent to having this exploit by default exploited.  

dewme

chadbag said:

The flaw affects all kinds of ARM-based chips — not just Apple's. 

But right above this line it says that the M1 is the first commercially available ARM based chip that offers the feature the flaw was found in.  In the last year have other ARM chips become commercially available with this pointer protection feature?

Also, chips without the feature don't have the protection in the first place, so it stands to reason that all other ARM chips are by default equivalent to having this exploit by default exploited.  

Yes, Apple is the first one to ship ARM based products with pointer authentication. Finding this vulnerability early on in the lifetime of the implementation this feature is a good thing and is in stark contract to the Spectre and Meltdown vulnerabilities, which were discovered much later in the lifetime of the features that proved to be vulnerable. In some sense finding PACMAN now has allowed an opportunity to close the barn door after only a couple of horses have escaped. Intel flaws were discovered after the entire herd of horses was on the loose for many years. 

As far as ARM chips that don't support pointer authentication are concerned, they are no more or less vulnerable to pointer related exploits as they were prior to the PACMAN discovery, but they are not exploitable by the PACMAN mechanism. There is a big difference. Any kind of pointer related exploit always runs the risk of being sussed out or revealed by virtue of it causing the attacked program to crash. The PACMAN attack takes advantage of two vulnerabilities to allow the attacker to use brute force techniques to  discover the protected pointer (the secret) value without crashing the program. Normally, you would expect any authentication protocol to catch anyone trying to guess the secret, as Apple does with device logins, so coming up with a way to neuter that added layer of protection is a big deal.

The attacker has to set up a lot of non-trivial scaffolding to implement a PACMAN attack, but this team at MIT has demonstrated that it is possible. 

Fred257

Good luck with this exploit unless they have physical access to your device:

” More than that, actually carrying out the PACMAN attack requires physical access to a device, meaning the average Mac user isn't going to be at risk of exploit.”

dewme

How did AppleInsider determine that physical access to the target device is required? I didn't see that mentioned at all in the MIT whitepaper. I've seen conflicting statements on other sites, for example https://www.tomshardware.com/news/mit-finds-vulnerability-in-arm-chips-demos-pacman-attack-on-apple-m1.

For what it's worth, I am not concerned about this specific exploit. It describes more of a class of vulnerabilities, not a specific exploit. However, it does bring to light and remind us that any unpatched vulnerability in hardware or software can serve as a jumping off point to enable other vulnerabilities. It's never enough to assume that vulnerabilities have a flat attack surface. They can be multidimensional and conditional on other vulnerabilities, much like ripple failures in hardware, software, and systems. As if a HW, SW, or systems designer's job wasn't already difficult enough ...

Marvin

dewme said:

How did AppleInsider determine that physical access to the target device is required? I didn't see that mentioned at all in the MIT whitepaper. I've seen conflicting statements on other sites, for example https://www.tomshardware.com/news/mit-finds-vulnerability-in-arm-chips-demos-pacman-attack-on-apple-m1.

The main site for it says it can be used remotely but it needs to be able to run code and they use C++, which sounds like they are transferring a compiled C++ executable over the network:

https://pacmanattack.com
https://pacmanattack.com/paper.pdf

"Does this attack require physical access?

Nope! We actually did all our experiments over the network on a machine in another room. PACMAN works just fine remotely if you have unprivileged code execution."

This is to circumvent a protection used to stop other attacks. So they have to get native code with memory access onto the device, use this attack successfully to bypass the protection, then run a different attack to do some damage. Getting native code onto a device in the first place would allow someone to do all kinds of damage anyway.

Security researchers get all excited about this stuff because they are stuck in a room all day testing these things but the results are mainly of interest to other security people. Apple commented on it with the following statement:

"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."

dewme

Marvin said:

dewme said:

How did AppleInsider determine that physical access to the target device is required? I didn't see that mentioned at all in the MIT whitepaper. I've seen conflicting statements on other sites, for example https://www.tomshardware.com/news/mit-finds-vulnerability-in-arm-chips-demos-pacman-attack-on-apple-m1.

The main site for it says it can be used remotely but it needs to be able to run code and they use C++, which sounds like they are transferring a compiled C++ executable over the network:

https://pacmanattack.com
https://pacmanattack.com/paper.pdf

"Does this attack require physical access?

Nope! We actually did all our experiments over the network on a machine in another room. PACMAN works just fine remotely if you have unprivileged code execution."

This is to circumvent a protection used to stop other attacks. So they have to get native code with memory access onto the device, use this attack successfully to bypass the protection, then run a different attack to do some damage. Getting native code onto a device in the first place would allow someone to do all kinds of damage anyway.

Security researchers get all excited about this stuff because they are stuck in a room all day testing these things but the results are mainly of interest to other security people. Apple commented on it with the following statement:

"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."

Agreed, the researchers have in effect demonstrated something that is possible, but carrying it out in the wild rather than in a lab and overcoming the obstacles and satisfying all the caveats is another thing altogether.

I have nothing but respect and gratitude for the researchers who are doing these kinds of investigations. It takes us so far beyond where we were 20 or 30 years ago when "just make it work" rarely {okay, never) involved doing even a shallow dive on potential security or privacy concerns. They are doing a fabulous job of finding latent issues baked into designs, not only at the surface but now much deeper down and conditional ones exposed by other issues. In most cases they are discovering these using reverse engineering and behavioral analysis, not by digging into the design artifacts that are only in the hands of the product owners. That's some pretty good detective work.

The only issue I have with some of these discoveries is that the target audience for the subsequent disclosures is often just the product owner, not the general public. In the spirit of transparency everything gets pushed out to everyone and makes for some exciting large font headlines, especially when a clever name is assigned. However, doing so can create anxiety in end users for issues that either don't really impact them or for which there is no mitigation, other than the product owner reassuring them that they have nothing to worry about.

Every controlled process requires a negative feedback loop. These researchers provide that necessary function and I wouldn't want it any other way. As far as public anxiety and scary headlines, it's just another one of many that everyone has to learn to deal with in our media saturated world.

macxpress

Sounds like it would be very difficult to actually execute in the wild, but this won't stop Apple haters from using this as an argument in the future when a topic of security, privacy, etc comes up. As typical, its someone who doesn't know what the hell they're talking about. They'll just look at headlines and post it to try and prove their point.