T0@stwe do not believe this issue poses an immediate risk to our users."

bonehead123Ok, 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 ????????

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.

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.

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


social.treehouse.systems/@marcan/113914534615474981

developer.arm.com/documentation/101550/0001/AArch64-registers/AArch64-register-descriptions/AArch64-Generic-System-control-register-description/SSBS--Speculative-Store-Bypass-Safe

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!

bonehead123Until it does, then what ????????

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

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

Visible NoiseThe 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.

lexluthermiesterThey'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.

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

AnotherReaderIt'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.

lexluthermiesterThat 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)

AnotherReaderI'm talking about the proof of concept code.

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

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

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.

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

lexluthermiesterRight, 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.

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.

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

Vayra86Well, 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.

Six_TimesI hear Ralph. "HA HA"