Apple Silicon Vulnerabilities Highlighted by FLOP & SLAP Side-channel Attacks

[T0@st]

An academic collaboration—between research departments at Georgia Institute of Technology and Ruhr University Bochum—has produced two white paper studies that disclose details regarding the vulnerable nature of certain generations of Apple Silicon. The documents were made available online earlier in the week; readily accessible through their Predictors.Fail webpage. The "SLAP" attack paper's moniker is derived/abbreviated from its long-form title: "Data Speculation Attacks via Load Address Prediction on Apple" Silicon. A similarly uncatchy acronymization has been generated by the second paper's full title: "Breaking the Apple M3 CPU via False Load Output Predictions"—aka "FLOP" attack. The North American and German security research teams have partnered up in the past—their "iLeakage" speculative execution side-channel attack was documented back in October 2023.

Spectre and Meltdown are the original, and likely most famous/notorious examples of speculative execution CPU vulnerability—owners of particular processor architectures were affected at the start of 2018. The Predictors.Fail bulletin proposes that the latest side-channel attacks affect Apple hardware of 2021 vintage and beyond. The teams introduced SLAP as: "a new speculative execution attack that arises from optimizing data dependencies, as opposed to control flow dependencies." They believe that Apple models: "starting with the M2 and A15 are equipped with a Load Address Predictor (LAP), which improves performance by guessing the next memory address the CPU will retrieve data from based on prior memory access patterns. However, if the LAP guesses wrong, it causes the CPU to perform arbitrary computations on out-of-bounds data, which should never have been accessed to begin with, under speculative execution. Building on this observation, we demonstrate the real-world security risks of the LAP via an end-to-end attack on the Safari web browser, where an unprivileged remote adversary can recover email content and browsing behavior."




Likewise, the security experts have outlined similar findings with FLOP—their paper demonstrates: "that Apple's M3 and A17 generation and newer CPUs are equipped with a Load Value Predictor (LVP). The LVP improves performance on data dependencies by guessing the data value that will be returned by the memory subsystem on the next access by the CPU core, before the value is actually available. If the LVP guesses wrong, the CPU can perform arbitrary computations on incorrect data under speculative execution. This can cause critical checks in program logic for memory safety to be bypassed, opening attack surfaces for leaking secrets stored in memory. We demonstrate the LVP's dangers by orchestrating these attacks on both the Safari and Chrome web browsers in the form of arbitrary memory read primitives, recovering location history, calendar events, and credit card information."

Bleeping Computer managed to extract an official response from Apple—following Georgia Tech and Ruhr U. Bochum staffers forwarding their findings to Santa Clara HQ. An anonymous Apple spokesperson stated: "We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats. Based on our analysis, we do not believe this issue poses an immediate risk to our users."

Phoronix's Michael Larabel kindly summarized these findings into a simplified list of Apple products: "all Mac laptops since 2022, all Mac desktops since 2023, and all iPhones / iPad Pro / iPad Air / iPad Mini models since 2021 are affected by these new SLAP and FLOP attacks."

View at TechPowerUp Main Site | Source

 

[bonehead123]

Ok, so just throw away all of your recent Apple devices & eat the $1000's of dollars you spent on them....OR

have the fruity bois come up with a patch for these vulnerabilities YET ?

we do not believe this issue poses an immediate risk to our users."

Until it does, then what ????????

 

[MentalAcetylide]

Ok, so just throw away all of your recent Apple devices & eat the $1000's of dollars you spent on them....OR

have the fruity bois come up with a patch for these vulnerabilities YET ?

Until it does, then what ????????

The scary thing is that "all" systems have their vulnerabilities, knowns, known unknowns, and unknown unknowns. Nevertheless, businesses like cheap, quick, & convenient more than they do security.

 

[AnotherReader]

Real World Technologies has a good discussion of this vulnerability. Apparently, AMD evaluated value prediction for the K9, but didn't think it was worth it in the end, and Ice Lake might have had it enabled before Spectre. As for context, Apple was given a lot of time and they still haven't addressed it:

SLAP

We disclosed our results to Apple on May 24, 2024.
Apple’s Product Security Team have acknowledged our
report and proof-of-concept code, requesting an extended
embargo beyond the 90-day window. At the time of writing,
Apple did not share any schedule regarding mitigation plans
concerning the results presented in this paper.

FLOP

Responsible Disclosure. We disclosed our results to Apple’s
Product Security Team on September 3, 2024. Apple has
acknowledged our disclosure and is continuing to investigate
our report.

 

[Visible Noise]

Turns out it's a big nothingburger and the "researchers" (students) should have read the ARM documentation.

Hector Martin (@marcan@treehouse.systems)

HA, so here's why I couldn't reproduce SLAP. m1n1 accidentally turns off the SSBS bit in PSTATE on EL0 calls. It defaults to 1 on CPU startup. [SSBS: Speculative Store Bypass...

social.treehouse.systems

Documentation – Arm Developer

developer.arm.com

Speculative Store Bypass Safe.

Prohibits speculative loads or stores which might practically allow a cache timing side channel.

A cache timing side channel might be exploited where a load or store uses an address that is derived from a register that is being loaded from memory using a load instruction speculatively read from a memory location. If PSTATE.SSBS is enabled, the address derived from the load instruction might be from earlier in the coherence order than the latest store to that memory location with the same virtual address.

0b0
Hardware is not permitted to load or store speculatively, in a manner that could practically give rise to a cache timing side channel, using an address derived from a register value that has been loaded from memory using a load instruction (L) that speculatively reads an entry from earlier in the coherence order from that location being loaded from than the entry generated by the latest store (S) to that location using the same virtual address as L.

0b1
Hardware is permitted to load or store speculatively, in a manner that could practically give rise to a cache timing side channel, using an address derived from a register value that has been loaded from memory using a load instruction (L) that speculatively reads an entry from earlier in the coherence order fro that location being loaded from than the entry generated by the latest store (S) to that location using the same virtual address as L.

The value of this bit is set to the value in the SCTLR_ELx.DSSBS field on taking an exception to ELx.

 

[_roman_]

Very nice. I think some other brand bring up patches faster.

Has anyone the CVE for that SLAP and SLOP please?

 

[AnotherReader]

Turns out it's a big nothingburger and the "researchers" (students) should have read the ARM documentation.

Hector Martin (@marcan@treehouse.systems)

HA, so here's why I couldn't reproduce SLAP. m1n1 accidentally turns off the SSBS bit in PSTATE on EL0 calls. It defaults to 1 on CPU startup. [SSBS: Speculative Store Bypass...

social.treehouse.systems

Documentation – Arm Developer

developer.arm.com

SSBS is off by default; ergo, the hardware is vulnerable. The authors also credited Hector:

While FLOP has an actionable mitigation, implementing it requires patches from software vendors and cannot be done by users. Apple has communicated to us that they plan to address these issues in an upcoming security update, hence it is important to enable automatic updates and ensure that your devices are running the latest operating system and applications.

Update: SLAP was found to have an actionable mitigation that also requires software patches. This is in the form of clearing the Speculative Store Bypass Safe (SSBS) bit, which is set by default. See @marcan's post for further details - thank you Hector!

 

[lexluthermiester]

Until it does, then what ????????

They're not wrong. While vulnerabilities exist, they require very special and difficult(read near impossible without direct physical access) conditions to exploit, situations made doubly difficult due to Apples walled-garden software business model.

While this is a thing, and very interesting, it's no different than all the other side channel attack types. It's worthy of notation and correction. It's not worth consumers worrying about.

 

[Visible Noise]

SSBS is off by default; ergo, the hardware is vulnerable. The authors also credited Hector:

The app is supposed to turn it on if it’s running untrusted code. It’s off by default on every arm chip.

Like I sad, they could have just read the ARM documentation. I hope they didn’t spend a lot of time “researching“ this.

 

[Vayra86]

The scary thing is that "all" systems have their vulnerabilities, knowns, known unknowns, and unknown unknowns. Nevertheless, businesses like cheap, quick, & convenient more than they do security.

Well, life's full of risk. Can't live a risk free life.

Its all a matter of risk assessment and having some plan in place when things fail. But fail they shall.

 

[AnotherReader]

The app is supposed to turn it on if it’s running untrusted code. It’s off by default on every arm chip.

Like I sad, they could have just read the ARM documentation. I hope they didn’t spend a lot of time “researching“ this.

The applications that don't turn it on include ones that definitely should, i.e. web browsers. The exploit works in both Safari and Chrome.

They're not wrong. While vulnerabilities exist, they require very special and difficult(read near impossible without direct physical access) conditions to exploit, situations made doubly difficult due to Apples walled-garden software business model.

While this is a thing, and very interesting, it's no different than all the other side channel attack types. It's worthy of notation and correction. It's not worth consumers worrying about.

No physical access is required; exploits can be deployed via JavaScript in your common web browsers. It's also concerning that Apple still doesn't use process isolation in Safari when Chrome and Firefox have used it since 2019 and 2021 respectively.

 

[lexluthermiester]

No physical access is required; exploits can be deployed via JavaScript in your common web browsers.

That is a myth that has yet to be PROVEN. None of the "examples" that were created years ago were actually functional or effective. Please don't perpetuate a myth.

It's also concerning that Apple still doesn't use process isolation in Safari when Chrome and Firefox have used it since 2019 and 2021 respectively.

And what does that say? For all the complaints I have about Apple, their security ethic isn't one of them. So if Safari isn't geared toward preventing side-channel attacks, what do you think they're actions are saying about the actual risk.
(hint it isn't one)

 

[AnotherReader]

That is a myth that has yet to be PROVEN. None of the "examples" that were created years ago were actually functional or effective. Please don't perpetuate a myth.

And what does that say? For all the complaints I have about Apple, their security ethic isn't one of them. So if Safari isn't geared toward preventing side-channel attacks, what do you think they're actions are saying about the actual risk.
(hint it isn't one)

I'm talking about the proof of concept code. Of course, there's no known exploit in the wild. Like you, I also think highly of Apple's approach to security so I'm surprised that they have had issues with site isolation. It seems to be an issue with Webkit as Chrome and Firefox implemented it long ago.

 

[lexluthermiester]

I'm talking about the proof of concept code.

Yeah, so am I. It didn't actually work to exploit the vulnerability. It only simulated it. Not the same thing.

Of course, there's no known exploit in the wild.

And there's a reason why, it doesn't actually work unless you can secure a specific type of direct system access which requires direct physical access a some point during the infiltration stage. Without that access there is no actual way to exploit a vulnerable system. The CIA has tried it, the NSA tried it and that list goes on. They all failed without direct physical access. It is an inescapable requirement.

 

[AnotherReader]

Yeah, so am I. It didn't actually work to exploit the vulnerability. It only simulated it. Not the same thing.

They actually managed to get sender and subject lines of emails from a separate tab that was using Proton Mail. ArsTechnica also had a good article about it.

FLOP requires a target to be logged in to a site such as Gmail or iCloud in one tab and the attacker site in another for a duration of five to 10 minutes. When the target uses Safari, FLOP sends the browser “training data” in the form of JavaScript to determine the computations needed. With those computations in hand, the attacker can then run code reserved for one data structure on another data structure. The result is a means to read chosen 64-bit addresses.

 

[lexluthermiester]

They actually managed to get sender and subject lines of emails from a separate tab that was using Proton Mail. ArsTechnica also had a good article about it.

Right, but the researchers had direct physical access to the testing devices and manually navigated to the attacking site, directly accessing the attacking code, deliberately. They also knew exactly what they were attacking and how. It was a directed, known-factor attack. The general public has little to no risk of vulnerability to these types of attack because the vector of a attack is VERY limited and the windows of attack is so small as to be effectively irrelevant.

The difficulty of execution is the key factor in all side-channel, mock-addressing type attacks. Is it possible? Yes. It is plausible? No. Has ANYONE succeeded in the wild? No, or at least not yet.

Now should someone find a way to pull it off in the wild, then we have a problem. That's hasn't happened(yet) in the 8ish years since the first iterations of these types of vulnerabilities were discovered and it's very unlikely too.

 

[AnotherReader]

Right, but the researchers had direct physical access to the device and manually navigated to the attacking site. They also knew exactly what they were attacking and how. It was a directed, known-factor attack. The general public has little to no risk of vulnerability to these types of attack because the vector of a attack is VERY limited and the windows of attack is so small as to be effectively irrelevant.

The difficulty of execution is the key factor in all side-channel, mock-addressing type attacks. Is it possible? Yes. It is plausible? No. Has ANYONE succeeded in the wild? No, or at least not yet.

Now should someone find a way to pull it off in the wild, then we have a problem. That's hasn't happened(yet) and it's very unlikely too.

I get it; the sky isn't falling. Nevertheless, even a theoretical remote exploit should be taken seriously. There are plenty of exploits that are leveraged by bad actors like the NSO group on behalf of other bad actors and we only learn of them after the fact. As for average users, I'll let H. L. Mencken say it more eloquently:

No one in this world, so far as I know—and I have searched the records for years, and employed agents to help me—has ever lost money by underestimating the intelligence of the great masses of the plain people. Nor has anyone ever lost public office thereby. The mistake that is made always runs the other way. Because the plain people are able to speak and understand, and even, in many cases, to read and write, it is assumed that they have ideas in their heads, and an appetite for more. This assumption is a folly.

Edit: I also found this exploit interesting, because it's the first confirmation of what some suspected: Apple is using load value prediction which no other vendor has been known to implement. Intel's Ice Lake might have been designed with it, but Spectre put paid to it seeing the light of day and AMD evaluated it for the cancelled K9, but concluded it had low return at that time.

 

[lexluthermiester]

I get it; the sky isn't falling. Nevertheless, even a theoretical remote exploit should be taken seriously. There are plenty of exploits that are leveraged by bad actors like the NSO group on behalf of other bad actors and we only learn of them after the fact. As for average users, I'll let H. L. Mencken say it more eloquently:



Edit: I also found this exploit interesting, because it's the first confirmation of what some suspected: Apple is using load value prediction which no other vendor has been known to implement. Intel's Ice Lake might have been designed with it, but Spectre put paid to it seeing the light of day and AMD evaluated it for the cancelled K9, but concluded it had low return at that time.

It would be folly to disagree with any one of those points. The factor to take in with this and all of these types of vulnerabilities is risk assessment. The difficulty to successfully exploit is so high as to make them all effectively near-non-existent risk. That's all I'm saying.

 

[MentalAcetylide]

Well, life's full of risk. Can't live a risk free life.

Its all a matter of risk assessment and having some plan in place when things fail. But fail they shall.

That's the thing though. They don't have one. All of the doctors' offices can't function without their computers; Walmart stores can't sell anything; you can't buy gas. There's a big difference between risk & abject stupidity. Granted, they all have some kind of redundancy, but there's the growing probability that even backups can be affected; especially if something is missed & is propagated to the backups.

 

[Six_Times]

I hear Ralph. "HA HA"

 

[Caring1]

I hear Ralph. "HA HA"

You mean Nelson.