New speculative attacks on Apple CPUs
predictors.fail
predictors.fail
All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" process in the address space.
By setting a different policy, sites can protect themselves against this.
I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a major performance hit, and I don't think any other browsers do it differently.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr...
Basically, there are three scenarios:
- Completely unrelated tabs (e.g. those you open manually, those opened via command-click, tabs opened via '<a target="_blank' ...>" or 'rel="noopener"' references etc.) – these are relatively easily isolated if the browser supports it at all. All major (desktop!) browsers now largely do this, including Safari.
- "Same browsing context group" (but different origin) sites. These can communicate via various APIs, and historically that was achieved by just letting them run in the same rendering process. But in the face of attacks such as this one, this can be insecure. Firefox and Chrome provide sandboxing via separate processes; Safari does not.
- Same origin sites (without any stricter policy). These can fully access each other's DOM (if they have an opener/opened relationship), so there's not really any point in having them live in different renderers except possibly for fault isolation (e.g. one of them crashing not taking the other down). As far as I know, all browsers render these in the same process.
Sites can opt out of the second and third category into the first via various HTTP headers and HTML link attributes. If we were to design the web from scratch, arguably the default for window.open should be the first behavior, with an opt in to the second, but that's backwards compatibility for you.
I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense.
Can you make a "Secure" CPU? In theory yes, but it won't be fast or as power efficient as it could in theory be. Because the things that allow those things are all possible side channels. This is why in theory the TPM in your machine is for those sorts of things (allegedly, they have their own side channels).
The harder question is "what is enough?" e.g. at what level does it not matter that much anymore? The answer based on the post above this is based on quite a lot of risk analysis and design considerations. These design decisions were the best balance of security and speed given the available information at the time.
Sure, can you build that theoretically perfect secure CPU? Yes. But, if you can't do anything that actually needs security on it because it's so slow; do you care?
The way this has been trending is that in modern systems, we try to move as much of the ‘critical’ security information processing to known-slower-but-secure processing units.
But, for servers, in virtualized environments, or when someone hasn’t done the work to make that doable - we have these attacks.
So, ‘specialization’ essentially.
So the Apple's argument that iOS can't have alternative browsers for security is a lie.
Security isn’t a one-bit thing where you’re either perfectly secure or not. If someone breaks into your house through a window and steals your stuff, that does not make it a lie to claim that locking your front door is more secure.
In any event, Apple’s claim isn’t entirely true. It’s also not entirely false.
Browsers absolutely require JIT to be remotely performant. Giving third parties JIT on iOS would decrease security. And also we know Apple’s fetish for tight platform control, so it’s not like they’re working hard to find a way to do secure JIT for 3P.
But a security flaw in Safari’s process isolation has exactly zero bearing on the claim that giving third party apps JIT has security implications. That’s a very strange claim to make.
Security doesn’t lend itself to these dramatic pronouncements. There’s always multiple “except if” layers.
Well, at least in this case it would have greatly increased security (since it would have allowed the availability of actual, native Chrome and Firefox ports).
And otherwise: Does Apple really have zero trust in their OS in satisfying the basic functionality of isolating processes against each other? This has been a feature of OSes since the first moon landing.
I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a penalty can opt their sites into the "same process" flag if really needed.
> I can't imagine there are many sites passing significant amounts of data through this
This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).
It truly boggles the mind as to how all the other browsers pull it off.
[1]: https://en.wikipedia.org/wiki/Inter-process_communication
Here I would agree with you though.
Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites.
And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.
I think they've gotten away with it because it's a pretty obscure setting and they say a bunch of things like "most users should not enable this, and if you do enable it you should expect things to break".
window.open, in some constellations, is an exception, because the opening and opened sites have an explicit communication facility available to them, unless at least one of the two explicitly opts out of it. As far as I'm aware, Safari also correctly implements that opt-out.
The only thing that Chrome and Firefox seem to be doing on top of that, as far as I understand, is to actually enforce process-per-site even for sites from the same "browsing context group" (i.e. all that can hold programmatic references to each other, e.g. via window.opener), which requires using IPC.
From the FAQ:
"For leaking secrets, both SLAP and FLOP are confined to the address space they are trained in. As pointed out by iLeakage, Safari lacks Site Isolation, a measure used to enforce that two different webpages not from the same domain can never be handled by the same process. Thus, in Safari it is possible for an adversary's webpage to be handled by the same process (and thus address space) with an arbitrary webpage, increasing the attack surface including LAP- and LVP-based exploits.
On the other hand, although Chrome is equipped with Site Isolation, we demonstrate that it is not a perfect mitigation. We show the real-world existence of corner cases, where two subdomains of the same site can be merged into one process, again leading to LAP- and LVP-based attacks."
Of course it would be better if Safari would do the same thing as Chrome and Firefox and just provide a separate process for all contexts, including those that can communicate per specifications. But there's something sites can do today to avoid this potential information leak.
Individual sites plugging browser + CPU security holes seems like a violation of separation of concerns. Yes, I hope every bank out there puts this workaround into their site ASAP, but that's hardly a solution for the flaw itself.
If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory.
Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.
It'd also weaken any security protection based on randomness (eg ASLR slide, pointer encryption keys).
https://source.chromium.org/chromium/chromium/src/+/main:con...
If Chrome itself is not aggressive enough, try the "Auto Tab Discard" extension.
Safari on the other hand doesn't even have Tab Sleep for whatever reason.
And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.
> Considerations for Safari. We emphasize the importance of site isolation [55], a mechanism preventing webpages of different domains from sharing rendering processes. Site isolation is already present in Chrome and Firefox [42, 55], preventing sensitive information from other webpages from being allocated in the attacker’s address space. While its implementation is an ongoing effort by Apple [3, 4], site isolation is not currently on production releases of Safari. On the contrary, we also reflect on [Webkit's memory allocator] libpas’s heap layout from Section 6.3, allowing sites to not only share processes, but also heaps. Partitioning JavaScript heaps by at least several memory pages per-webpage would prevent JavaScript strings from the target webpage from being allocated within the 255-byte reach of the LAP.
possible absent any performance concerns at all, yeah sure
I was actually thinking something more like a bytecode interpreter that runs one operation and then sleeps until the next full wall clock second, but yes, that's my point: If you don't care about performance, you can make process isolation safe very easily.
Even Chrome, which pioneered the "tab per process" model, didn't isolate same browsing group context sites for a long time, and still shares processes on Android as a resource optimization: https://chromium.googlesource.com/chromium/src/+/main/docs/p...
Firefox only released their "Project Fission" in 2021, i.e. three years after Spectre.
Remarkably, while all other load widths activate the LVP
on any constant value fitting that width, we observe that acti-
vation on 8-byte wide loads occurs only when the load value
is zero. We conjecture that this may be a countermeasure for
memory safety such that the LVP will not learn values of
pointers. That is, with the M3 being a 64-bit CPU, pointers
are 8 bytes wide. Furthermore, on 64-bit macOS executables,
any virtual address below 0x100, 000, 000 is invalid.> any virtual address below 0x100, 000, 000 is invalid.
That kinda suggests that all 32bit addresses are inherently invalid on 64bit MacOS
> In order to make cache hits distinguishable from misses in Safari, we reference the NOT gate-based cache amplifica- tion primitive from [29, Section 5], adjusting the speculation parameters for the M2 CPU. We run the amplifier 500 times when the target address is cached and 500 more times when it is evicted, in native and WebAssembly implementations. Table 3 summarizes the timing distributions, with units in ms. We observe that they are clearly separable even in a web environment, allowing us to distinguish cache hits from misses with WebKit’s 1 ms timer.
So i guess all the hub hub around disabling fine resolution timers and SharedArrayBuffer was for naught.
It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone.
That seems like a bit of a reach. Its an obscure feature that is rarely useful, and when it is all you have to do is send the right http header (if using chrome) and you get it back.
Did use cases exist? Sure. But not sufficiently to move the needle on app store usage.
Web games benefit significantly from SAB (see the Godot engine for example) and mobile games make up a pretty sizable chunk of app store usage, particularly in app purchases.
We can't say that for sure. There is no shortage of examples where Apple neglects a feature that might provide parity with their own services to avoid competition. Safari, being a mandatory feature of iOS, is reasonably implicated as part of the conspiracy to prevent users from buying and selling software without the assent of a corporate benefactor.
Did anyone spot where this is mentioned?
Edit: it doesn’t seem like they have a general attack. Rather, it’s that some sites are not in the public suffix list.
Edit 2: It’s also interesting that they found that iPhone 13 and iPhone 13 mini (which have the same processor and came out at the same time) differ in LAP in that they observed only the latter as having it. Very curious…
A PSL flaw is important, but also a low-cost fix.
Thanks for pointing this out.
Especially now that I have just bought an M4 mac
That and it moved to Arm’s 9.2 instructions.
Apple acknowledged the shared proof-of-concept and stated it plans to address the issues. However, at the time of writing, the flaws remain unmitigated.
"We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats," Apple told BleepingComputer.
"Based on our analysis, we do not believe this issue poses an immediate risk to our users."
Is there an example in the wild of a spectre exploit stealing my gmail cookie and doing something with it? (Would be difficult since it's tied to other fingerprints like my IP)
Or stealing credit card numbers when they're in memory after I place an online order?
For regular end-user desktop machines, the mitigations only decrease performance for no real benefit. Spectre is a highly targeted attack, it's not something you can just point at any random machine to retrieve all their bank passwords or whatever.
Perhaps, but I am not under this misunderstanding and never expressed it.
> Only specialized software/scenarios will tangibly benefit from the parasitic gains of SMT-induced extra parallelization
In my experience it also speeds up C++/Rust compilation, which is the main thing I care about. I can't find any benchmarks now but I have definitely seen a benefit in the past.
> video encoders like x264 or CPU-bound raytracers to name a few examples. These gains typically amount to about 15-20% at the very extreme end.
Normally those types of compute heavy processes, data streamlined, processes don’t see much benefit from SMT. After all SMT only provides a performance benefit by allowing the CPU to pull from two distinct chains of instructions, and fill the pipeline gaps from one thread, with instructions from the other thread. It’s effectively instruction-by-instruction scheduling of two different threads.
But if you’re running an optimised and efficient process that doesn’t have significant unpredictable branching, or significant unpredictable memory operations. Then SMT offers you very little because the instruction pipeline for each thread is almost fully packed, offering few opportunities to schedule instructions from a different thread.
The only real constraint is that you can actually leverage multiple threads. For protos as an example, that requires a modified version of the format with checkpoints or similar (which nobody does) or having many to work on concurrently (very common in webservers or whatever).
Edit: Arbitrary memory access, not ACE
The amount of actual exploit crafting that is needed to actually do something meaningful with a hack is pretty much not worth doing for any financial reason. The only time this happens now is when state funded actors or prominent groups with lots of manpower really want to take down an individual person.
Probably, but there’s a huge luck element involved, at least with spectre. It’s difficult to guide the speculative execution to read exactly what you want it to read, assuming you even know where it is. As a result you need to spend quite a bit of time on a single target before you’re likely to actually get the data you want. Even then, there’s likely a significant element of human analysis to assemble something useful from all the noise.
So yes, it’s almost certainly possible. But exploits don’t exist in a vacuum. If you’re expending that much effort to get credit card numbers, then quite frankly you’re a fool, because good old phishing attacks and other social engineering attacks are easier, more reliable, and above all, cheaper.
At the end of the day, crime is a business like any other, profitability and margins are king. You don’t waste time perfecting attacks that have significantly smaller margins than your existing attacks. The only exception to that is nation states, because they aren’t motivated by directly extracting cash from victims, and ultimately that’s what makes nation state actors so dangerous.
Spectre is not an arbitrary code execution kind of attack.
DuckDuckGo works fine with no JS.
This gets repeated on every thread about speculative execution exploits, but I think people who say this are underestimating how huge the difference would be. I suspect processors without speculative execution would be many times slower, not "a bit".
In the early days there was a ~10% hit, but that's changed a lot since then.
1. Read Flush + Reload
2. Then reproduce it in C
3. Then read Meltdown
4. Reproduce it in C
5. Read Spectre
6. Reproduce it in C
After that we had to implement a VUSEC paper. I chose GLitch [1].
A spectre (particularly RSB-based ones) are nice to start out with imo.
Here, they claim to have a remote exploit vulnerability. It's not that Apple is leaking data, it's that the CPUs have a bug where they appear to be actually executing code based on incorrectly-loaded ("predicted") data.
Though the details are, as is usually the case, thin. I await further analysis.
Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim.
But "the same flavor of vulerability" seems to be a mischaracterization.
Some of the earlier speculation attacks didn't get to do arbitrary compute on the speculated data, they could only for example influence whether something was loaded into cache or not.
This makes an attack easier to write.
The ARM ISA and also other ISAs with fixed-length instruction encoding are an exception. Because they have a fixed instruction length, typically of 32 bits, most constants cannot be embedded in the instruction encoding.
As a workaround, when programming for such ISAs, the constants are stored in constant pools that are close to the code for the function that will use them, and the load instructions load the constants using program-counter-relative addressing.
Frequently such constants must be reloaded from the constant pool, which allows the load value predictor to predict the value based on previous loads from the same relative address.
In contrast with the Apple ARM CPUs, for x86-64 CPUs it is very unlikely that a load value predictor can be worthwhile, because the constants are immediate values that are loaded directly into registers or are directly used as operands. There is no need for constants stored outside the function code, which may be reloaded multiple times, enabling prediction.
All fast CPUs can forward the stored data from the store buffer to subsequent loads from the same address, instead of waiting for the store to be completed in the external memory. This is not load value prediction.
I think you're making a good point about immediate encodings probably making ARM code more amenable to LVP, but I'm not sure I totally buy this statement.
If you take some random x86 program, chances are there are still many loads that are very very predictable. There's a very recent ISCA'24 paper[^1] about this (which also happens to be half-attributed to authors from Intel PARL!):
> [...] we first study the static load instructions that repeatedly fetch the same value from the same load address across the entire workload trace. We call such a load global-stable.
> [..] We make two key observations. First, 34.2% of all dynamic loads are global-stable. Second, the fraction of global-stable loads are much higher in Client, Enterprise, and Server work-loads as compared to SPEC CPU 2017 workloads.
Some of the global-stable values are reloaded because the ISA does not provide enough explicitly-addressable registers, despite the fact that a modern CPU core may have 10 times to 20 times more available registers, which could be used to store the global-stable values.
This is one of the reasons why Intel wants to double the number of general-purpose directly addressable registers from 16 to 32 in the future Diamond Rapids CPU (the APX ISA extension).
In other cases the code is not well structured and it tests repeatedly some configuration options, which could be avoided by a proper partitioning of the code paths, where slow tests would be avoided and the execution time would be reduced, even at the price of a slight code size expansion (similarly to the effect of function inlining or loop unrolling).
Sometimes the use of such global-stable values could have been avoided even by moving at compile time the evaluation of some expressions, possibly combined with dynamic loading of some executable objects that had been compiled for different configurations.
So I have seen many cases of such global-stable values being used, even for CPU ISAs that do not force their use, but almost none of them were justified. Improving such programs at programming time or at compile time would have resulted in greater performance improvements, which would have been obtained with less energy consumption, than implementing a load-value predictor in the CPU.
I do wonder if there are other common code patterns that a practical LVP could exploit. One that comes to mind immediately are effectively constants at one remove: Think processing a large array of structs with long runs of identical values for some little-used parameter field. Or large bitmasks that are nearly all 0xFF or 0x00.
Otherwise, there are known examples of related-but-less-aggressive optimizations for resolving loads early. I'm pretty sure both AMD[^1] and Intel[^2] have had predictive store-to-load forwarding.
edit: Just noticed the FLOP paper also has a nice footnote about distinguishing LVP from forwarding during testing (ie. you want to drain your store queue)!
[^1]: https://www.amd.com/content/dam/amd/en/documents/processor-t...
[^2]: https://www.intel.com/content/www/us/en/developer/articles/t...
IIRC this was how Spectre Variant 4 worked.
Mark Twain
Memory is slow. Insanely slow (compared to the CPU). You can process stupid fast if your entire working set can fit in a 2KB L1 cache, but the second you touch memory you're hosed. You can't hide memory latency without out-of-order execution and/or SMT. You fundamentally need to be parallel to hide latency. CPUs do it with out-of-order and speculative execution. GPUs do it by being stupidly parallel and running something like 32-64 way SMT (huge simplification). Many high-performance CPUs do all of these things.
Instruction level parallelism is simply not optional with the DRAM latency we have.
But I was just really trying to point that in-order cpus are still around, they did not disappear with in-order atom.
I dont think its inevitable, might be caused by greed. You could have small separate sections of cache (or additional tag) dedicated to per thread speculation, but no designer is willing to sacrifice real estate to something that will be thrown away the instantly.
No. Processors with no branch prediction would be many times slower (up to dozens of times slower on workloads that don’t fit in cache)
If that's not true, then someone's going to figure out exactly how to set bounds on safe speculation and that will become part of future CPU designs.
I wonder if this is the kind of grant that is no longer being funded (or at least "paused")
I only bring it up because one of the reasons I use Safari with private browsing as a default is because, if I were to login to a site like Facebook in one tab, open a new private tab in the same window and try going to Facebook, it would not recognize that I had already logged in from the other tab. Chrome nor Firefox do that.
"Based on our analysis, we do not believe this issue poses an immediate risk to our users."
https://www.bleepingcomputer.com/news/security/new-apple-cpu...
Sometimes they mean "no we don't think it's exploitable", sometimes the charitable reading is "we don't think anyone is exploiting this and we think developing an exploit will take quite some time".
Unfortunately they never reveal exactly that they mean. This is very annoying, because when it's the former case, they're often right! Security researchers publish bullshit sometimes. But the vendors basically leave you to figure it out for yourself.
"1.2. Responsible Disclosure
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. "
remember the iphone 6 battery and butterfly keyboard gate we both "small number of users" according to Apple.
[2] https://developer.apple.com/documentation/xcode/writing-arm6...
However I also expect that Swift-compiled apps can do this without a web browser component.
It’s a different threat model though, having installed a malicious app vs browsing a malicious site.
Having said that there are apps that are considered mainstream and not malicious by the general population but can become a convenient backdoor for, say, a state actor.
> 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.
"Side channel attacks are a class of exploit that infers secrets by measuring manifestations such as timing, sound, and power consumption"
I know it's kind of goofy, but I don't really see the downside to it.
Definitely not just hardware exploits though. Look at heartbleed for example. It's been going on a long time. Hardware exploits are just so much more widely applicable hence the interest to researchers.
It is difficult to prove their effort. One security-related bug removes everything, even if it happened only once in 10 years in 1 million line code base.
Well I'm shocked, for such a company that promotes security and privacy, apple not having put site isolation into safari seems amateurish.
You can have security without privacy but you can't have privacy without security, when they promote privacy they also claim to be secure.
No website isolation goes against both of these principles.
The vulnerability is over half a year old and over a quarter over the embargo window.
Intel requested an embargo for 21 months for SRBDS/Crosstalk.
For Downfall, a more recent one, Intel requested a 12 month embargo to release a microcode update.
Most browsers have already switched to process-per-site because of Spectre.
https://pxlnv.com/linklog/apple-bug-bounty-troubles/
https://www.marketplace.org/shows/marketplace-tech/looking-f...
https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
https://security.apple.com/blog/apple-security-bounty-upgrad...
Would be interesting to see if it made a difference.