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