iLeakage: Browser-Based Timerless Speculative Execution Attacks on Apple Devices
ileakage.com
ileakage.com
- Is this a Webkit vulnerability or a Safari vulnerability?
- Does enabling Lockdown mode mitigate this vulnerability, seeing as mobile Safari doesn't expose these dev settings?
- What's the timeline on the disclosure to Apple?
Edit: they updated the page to answer the last question:
When did you notify Apple?
We disclosed our results to Apple on September 12, 2022 (408 days before public release). When did you notify Apple?
We disclosed our results to Apple on September 12, 2022 (408 days before public release).Good that they've added it. Disappointing to see that Apple has gone so long without releasing a fix.
Yes (with a very high chance), if you have a device running macOS or iOS with Apple's A-series or M-series CPUs. This includes all recent iPhones and iPads, as well as Apple's laptops and desktops from 2020 and onwards.
This is technically a Hacker News Favorite Processor a.k.a. M1/M2 vulnerability. However all relevant CPUs on the market now has the same vulnerabilities so it became a feature so software has to be designed to mitigate it.
It is impractical to get rid of all possible Spectre gadgets from WebKit, so the browser should be designed to leverage OS's Spectre mitigation to deal with these vulnerabilities (i.e. isolate different websites in different processes).
And, in the FAQ:
> Ultimately, we achieve a out-of-bounds read anywhere in the address space of Safari's rendering process.
So, in my opinion, this is a Safari vulnerability: they hold Site Isolation wrong.
> So, in my opinion, this is a Safari vulnerability: they hold Site Isolation wrong.
Previously, something I would normally consider a Safari specific bug (IndexedDB storage not being isolated to its owning web page) also made it into Gnome Web and various other WebKit browsers. Site Isolation is enabled on other browsers but as an outsider I have no idea if that is normally handled by WebKit or by the surrounding framework.
It looks like Gnome Web/Epiphany is safe at least: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/448 but there are plenty of WebKit implementations out there, such as cars and video game consoles.
I don't understand what you mean when you say the vulnerabilies to speculative exucution side channel attacks is a CPU "feature." Could you expound on your meaning there?
In my mind, a CPU feature would be something like out-of-order execution or integrated memory controllers. Isn't this more of a side effect (or an "oh shit..."). For example, I'd consider speculative execution to be a feature of CPUs with a side effect causing these vulnerabilities to side channel attacks, much like weight loss is a feature of the medicine Xenical (orlistat) with a side effect causing anal leakage.
Also, mitigations for newly discovered spectre-like attacks have to be done software side, but successive processor generations will bake those mitigations into the silicon to reduce the performance penalties associated with software fixes.
This is not correct. Spectre-like bug in the same privilege domain (as to the CPU) is just unfixable. Meltdown, L1TF etc were fixed in hardware because they leak data across hardware enforced privilege domains (i.e. userspace/kernel/enclave), in this sense it is a hardware bug.
In case of browser, the CPU feature is "CPU is eager to leak arbitrary data in the same address space even if on the face the code does not seem to do it". This can't be fixed in the hardware because it's not a hardware bug: there's no hardware implemented security boundary, it's purely software defined.
> - Is this a Webkit vulnerability or a Safari vulnerability?
Safari.
"...iLeakage exploits idiosyncrasies in Safari's JavaScript engine..."
> - Does enabling Lockdown mode mitigate this vulnerability, seeing as mobile Safari doesn't expose these dev settings?
Yes.
"Lockdown Mode does mitigate our work by disabling just-in-time (JIT) compilation in Safari, which is a performance feature used by iLeakage to build its attack primitives."
> Not for the most part. In fact, we encourage using credential managers as opposed to trying to remember all of your passwords. In general, this is a better approach than reusing passwords or storing them insecurely. While iLeakage can recover credentials that are autofilled into a webpage, we note that many platforms require user interaction for autofill to occur.
Why would use of a credential manager change this? If its leaking something out of memory it should effect all memory within the Safari process space? I'm not familiar enough in this area to understand this caveat.
b) you are safer yet if you turn off automatic autofill and instead use a hotkey or some other form of user interaction
Change what?
>If its leaking something out of memory it should effect all memory within the Safari process space?
AFAIU, Safari generally puts different origins and extensions in different address spaces, so it's not vulnerable to speculative execution attacks. This attack found a way to make 2 different origins share the same address space. I'm assuming the attack doesn't apply to extensions. From the paper:
>We begin by abusing Safari’s site isolation policy, demonstrating a new technique that allows the attacker page to share the address space with arbitrary victim pages, simply by opening them using the JavaScript window.open API.
- Having a password manager is good for lots of other reasons, and at least means that only one website is compromised if the password is stolen
- Their technique could probably also steal session tokens, which isn't quite as bad as stealing a password but is still bad.
- Password managers can be configured to require a click to fill in the password, which also defeats this attack.
> Here, we show that our attacks have near perfect accuracy across Safari, Firefox, and Tor.
Moreover, is the attack via `window.open()` really specific to Webkit, or is Webkit just the only engine that was studied in depth for this study? Notably, `window.open()` implies a shared context between the calling window, which receives a reference to the newly created window, and the new window, which has a back reference via `window.opener`. Do other browser engines achieve perfect isolation?
https://www.chromium.org/Home/chromium-security/site-isolati...
> Taking this approach a step further, Safari follows a simple one process per tab model, where two web- pages are never consolidated into the same rendering process, even under high memory pressure and even if they share an eTLD+1 in their URLs. Instead, Safari spawns a new rendering process for each tab until the system runs out of memory.
It's only in the context of `window.open()` that this isolation strategy is defeated. Given that both the calling window and the newly opened window share mutual references to each other, isn't the next side channel attack lurking around the corner, even if these windows are rendered by separate processes?
> Given that both the calling window and the newly opened window share mutual references to each other, isn't the next side channel attack lurking around the corner, even if these windows are rendered by separate processes?
Non-same-origin opener references only allow very restricted operations. It is possible that there are undiscovered issues, but it is a lot less powerful than running in the same process. It isn't like having a raw pointer from one window to another.
This also goes to show how the side channel mitigations are totally useless and we should stop pretending such attacks have been fixed. It is not safe to run untrusted code, no matter how you sandbox it. Not on a host using a modern CPU running multiple applications.
>At the time of public release, Apple has implemented a mitigation for iLeakage in Safari
However the site gives no details on timelines or a report at all.
(edit) They have added a "When did you notify Apple?" to the FAQ.
ETA: To be clear, this isn't me speculating. I spoke with one of the authors and asked this specific question. Apple hadn't shared the mitigation with them as of a few days ago.
> We disclosed our results to Apple on September 12, 2022 (408 days before public release).
Edit: The below comment is correct, I was looking at a similarly named item "Swap Processes on Cross-Site Navigation" - it appears this is not enabled by default right now.
Edit: It appears I confused it with a similarly named flag. It doesn't appear to be enabled on macOS yet by default.
Edit: Seems like I got confused by the other very similar feature flag as well.
"Swap Processes on Cross-Site Navigation" is enabled by default, but this paper recommends "Swap Processes on Cross-Site Window Open".
> That is, while the speculative JavaScript sandbox escape is still possible, an attacker becomes limited to reading their own address space and therefore their own data. Finally, at the time of writing, Apple’s patch is publicly available [57] and is implemented in Safari Technology Preview versions 173 and newer [58].
[57] is https://github.com/WebKit/WebKit/pull/10169. At the bottom of it, an engineer continues to link ongoing hardening patches for window.open() + process isolation.
It looks like apple has had over 400 days to fix this. That's already more time than I'd have given them. It's far better that apple users are told what their risks are than to just leave apple users ignorant of the danger for another year+ by not saying anything while praying that nobody else is already aware of the flaw and quietly exploiting this.
I'm all for giving companies time to fix their bugs, but at a certain point it becomes more irresponsible to not inform the people impacted.
Because the last bastion of privacy and security have sat 400+ days on this without fixing it. I wouldn't blame the finders for making it public before the fix is rolled out, rather Apple for sitting on their hands for so long.
Presumably because fixing this required changing the processes model in WebKit, which means they are still testing the change before landing it for everyone.
> This also goes to show how the side channel mitigations are totally useless and we should stop pretending such attacks have been fixed. It is not safe to run untrusted code, no matter how you sandbox it.
All side-channel attacks have not been fixed, but I think it is inappropriate to call side channel mitigations useless. They significantly raise the bar for exploitation, much like seatbelts aren't "useless" even though people still die in car crashes. And I don't know about you, but I still drive cars even though I'd love to find ways to improve their safety.
Really interested to find out why Apple has (mostly) slept on this for over a year!
They are one of the CVE gods, so they can veto issuance of CVEs against their products. That kind of power means you can move as slowly as you please.
> "To mitigate our work, Apple has just released iOS 17.1, iPadOS 17.1, and macOS Sonoma 14.1. Update your devices now!"
Which they have now reverted.
https://github.com/ileakage-authors/ileakage-authors.github....
Yet another scary nickname and domain name for it says unprofessional and untrustworthy to me.
IMHO if you're being targeted by a nation-state actor, or otherwise someone who knows enough about your hardware and software environment to be able to do something like this, there are far more important things to worry about.
All these side-channels require a lot of setup and can be easily perturbed by other unpredictable sources of noise in the environment.
An attack vector is available, they'll abuse it if they can. Do you think I'm overestimating them ?
as a rare Intel Mac owner, I guess I am not affected then
That might be the customer's expectation, but that isn't what Apple is providing. We've time and again seen that the default configuration is not secure. Apple has known about this bug for more than a year now, and the only protection remains to use lockdown mode.
Demanding absolute security on the default configuration is unreasonable. No platform provides that.
That's not what we're expecting. Most consumer platforms provide fixes for known secret-stealing vulnerabilities in the order of weeks. What we're seeing here is an outlier.
defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1
Make sure your terminal has Full Disk Access and try again.
By default only small amount of js execution is allowed for web pages (small event handlers and such). If a page tries to execute more js, browser should ask user's permission to extend the limit. (Maybe several levels of the limit should be supported?). Some web pages could be added to a permanent list of trusted domains with permanently increased limit.
Upd: 4-5 minutes, in the first video (https://youtu.be/Z2RtpN77H8o?si=XB4oI9ner8pFTIqN) - see the time on the top right of their screen. When the attack starts it's 5:22, ends at 5:27.
Also, a "no, and don't ask again" button would be very useful in this case.
Such a setting whould also reduce malicious crypto mining possibilities.
It doesn't close the vuln and just adds un-necessary friction for users.
Can't wait for passkeys to replace passwords everywhere.
Chrome and Firefox both support Out-Of-Process Iframes as part of their security setup; though I'm not sure if Firefox has it enabled by default yet. Firefox even drew some lovely pictures about it here: https://hacks.mozilla.org/2021/05/introducing-firefox-new-si...
Is this not covered by lockdown mode on iOS? Crazy.
> defaults write com.apple.Safari IncludeInternalDebugMenu 1.
if you get
> Could not write domain /Users/YourUser/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari; exiting
instead you can check in the "develop" menu of safari , and section "feature flags"
The mitigation seems to be to split the process space.
From the paper:
Attacking Gmail. With Google being one of the world’s largest email providers, it is highly likely for a target to be signed in with their personal account. By having the event listener inside the attacker’s page access execute window.open(gmail.com), we can consolidate the target’s inbox view into the attacker’s address space. We then leak the contents of the target’s inbox, see Figure 11.
Recovering Android Text Messages. Android users can send and receive text messages from a browser window by pairing their phone with Google’s Messages platform. Thus, by opening Google Messages using window.open(), we can recover a target’s text messages without attacking their mobile phone itself.My understanding is that the theory of this attack was introduced with Spectre. iLeakage adds enough research to create a working proof-of-concept, plus acknowledgment that, as of last year, it wasn't addressed in Safari.
More on site isolation (the functionality that mitigates these attacks):
https://w3c.github.io/webappsec-post-spectre-webdev/ https://www.chromium.org/Home/chromium-security/site-isolati... https://blog.chromium.org/2021/03/mitigating-side-channel-at...
I'd not be surprised if accounts used in troll farms /bots/ are stolen this way.
Is there some secret world I don't know about that's driven by how banger your vulnerability disclosure presentation is? Every one anymore has a full site. Is this what it takes to get attention these days? Everything, including computer bugs, needs a marketing campaign? Every time I see these sites I roll my fucking eyes at how ridiculous it is that people keep making them, but it seems to only be increasing in occurances.
Can someone explain this to me because I feel like I'm missing something. Just feels like peak consumerism and attention economy bs that shouldn't be needed imo, but I hope I'm missing some crucial thing that makes these valid
I'm sure keen folk can digest SCM pull requests, but that population is a super minority I think to well presented content disseminated on youtube, sites, blogs, etc.
I don't think CVE being mandated as the only place vulnerability/conversations are had would be optimal, no?
I know HN frowns on grammar-policing comment, and rightly so; but I thought nonetheless you might like to know (and it looks so much more formal this way anyway!) that it's "smörgåsbord" (or the diacritics are commonly omitted in English).
I think it's just a trend for any any huge-scale vulnerability research team to put together a website for it, as that amount of effort will indicate a certain level of attention the exploit requests of the reader / the security community at large.
And it doesn't always happen. Log4shell, for example, was not its own website: https://news.ycombinator.com/item?id=29504755
Feels like a dangerous way to gauge the severity of issues. What if the discloser doesn't have the funds or the skills to setup a dedicated website? Will it not get any attention since there's no yodawgiheardyoulike0days.com website to float up to the top of HN? This is what CVE severity scoring is for and what should be used, not the presence of a dedicated website, no?
Evidently they just get ignored, if their account of direct disclosure to Apple is anything to go off of.
Clearly we need Vulnerability Website as-a-Service (VWaaS).
.
People have all sorts of miscalibrated heuristics with which they judge things. Regardless of the originators intentions.
Seems rather unproductive to question why the site exists when your problem is with people using the existence of the site to make decisions.
I would argue that the people who think the existence of a website is a good gauge for vulnerability severity need to have a refresher on how to gauge vulnerability severity. The inability/lack of education in how to assess severity is the root of the problem in my opinion.
War of the Worlds was broadcast and people freaked out that aliens were invading. I don't think they tracked each of those people down and told them to not be so stupid, they started adding disclaimers to the broadcasts so people coming in late or whenever they would know it was a story and fiction. They fixed the problem not the symptoms.
It could just be that the researcher is immensely proud of their work and wants to show it off with its own website, logo, clever name, etc.
one of these things is not like the other
Same can be said for personal blogs. The purpose is showing off. By the way, setting up a server nowadays is ridiculously easy and cheap. If you have done it a few times and you use a simple static site stack with CI then you can have a site live in 15-30 minuted including SSL and hosting for free (GitHub Pages, Cloudflare, or GitLab Pages for example).
And the problem here is that Apple and other companies don't address these vulnerabilities until someone forces their hand. That's why a "marketing campaign" is required, unfortunately.
This should be a reason to lift this policy and allow different engines on these devices!
uarch "multiculture" hasn't saved us from architectural attacks, actually it probably increases the total number of vulnerabilities, and browser multiculture won't magically make them all perfectly secure and perfectly implemented either. if each browser is only 99% secure now you have 0.99^3 total security, you have ~tripled your odds of a vulnerability existing in at least one of your apps at a given time.
there are other arguments in favor of sideloading, but, I don't really see how multiple browsers is a security improvement, actually it seems unironically much worse on that front, since now you are depending on three teams of engineers (two of which are not even at your company) to execute perfectly and never have a vulnerability, in what is one of the highest-privilege applications (essentially the canonical "full control" app). People want their browser to have access to location info (thus bluetooth/wifi settings), camera, camera roll (thus long-term location history), microphone, everything. The fewer applications that exist like that the better you are.
I can't fathom anyone saying that they should, for example, run three different high-privilege pieces of software in their production systems, when one would do fine - f.ex you wouldn't run nginx, apache, and keycloak all mixed into your environments. That would obviously inflate the risk of being subject to at least one attack. Why is the browser different?
Having options does not reduce your security except in-so-far as exposing the underlying mechanism allowing choice increases your attack surface, and even then that does not inherently reduce your security. A mechanism allowing multiple implementations requiring more available attack surface, but which is used by a high quality application to provide a highly secure implementation is still better than a reduced mechanism designed to only allow a single application when that application provides a low quality implementation.
Also, the argument you just proposed could just as easily be used to argue that we should disallow any other operating system other than Windows 3.1 since having more operating systems just increases the attack surface. That is patently absurd for the reasons I just stated above and is why your argument is fatally flawed.
This is not true. The moment Apple allows different browser engines, my Gmail app would use blink. As a browser, I’d maybe use Firefox/gecko and all Apple apps would still use the embedded WebKit.
Yes, this is my choice and I would do it knowing I’m increasing my attack surface, but apple‘s reasoning is not false…
Meanwhile having the choice is a security advantage because a) the user could choose the one with the best security record, whether or not it's Apple's and b) if there is an active vulnerability in Safari today then the user can use Chrome or Firefox today, and then do the reverse on the day there is an active vulnerability in Chrome.
The main concern people seem to have with this is the one which is also caused by Apple -- apps might embed a browser engine and then if it's vulnerable you have to update lots of apps. But this is only because of their lacking support for independent libraries. If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once. That problem is only caused by this not being supported.
And is a problem that extends to more than browser engines. Apps can't use their own browser engines, but they might incorporate some common third party code that doesn't require JIT compilation, and then if someone finds a vulnerability in that code you still have to update a zillion apps. Specifically because the code isn't distributed as a dynamic library by its developers and instead gets copied into each app independently -- which not only impairs security but takes up more storage and memory to have multiple copies of the same code.
That doesn't seem true, I can easily imagine an app that's based on Firefox but can still cause a WebKit page to open, you just need a system API that uses WebKit.
> If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once.
That's not how the app update lifecycle works, they're all independent. (Otherwise they'd break a lot more easily.)
It's still not using two different browser engines for the same purpose. This is no different than having two different apps that each use a different browser engine. The attacker needs the app to be using the exploitable browser engine in the context where they can deliver an attack payload, not in some other context.
You can also improve this situation for system APIs by making the API open the page using the user's default browser instead of one hard-coded by the system or the app.
> That's not how the app update lifecycle works, they're all independent. (Otherwise they'd break a lot more easily.)
Breakage isn't common when systems implement this properly. When you get the new version of libssl from apt, all the packages that depend on it get updated and it's unusual for any of them to break.
We don't want to go back to DLL hell, do we? History has shown that this approach does not scale, and definitely not on mobile.
Meanwhile you still don't need a thousand versions installed because the library only has to declare a version compatibility change if some part of the API is removed. Otherwise a newer version of the library will implement everything an older version does and only make additions or bug fixes.
Then you have some app which needs library version 2.3.4 or higher, some other app needs the same library with version 2.3.5 or higher, so the system sees those dependencies and installs version 2.3.9 which is backwards compatible and can be used by both of those apps. An old app needs version 1.2.0 or higher, which isn't compatible with 2.3.9, so the system installs version 1.2.15, which is. Then you have two versions of the library installed alongside each other instead of the three versions you have now -- and the two versions you have installed are both still maintained, instead of having apps that quietly statically include versions 1.2.0 and 2.3.4 which each have a big fat CVE, and 2.3.5 which patched the security vulnerability but still has a couple of inconvenient bugs you don't need.
This is all done by a package manager which uses the list of dependencies for each app to take care of it for you when you install an app. This has been a solved problem for decades. But mobile fails to implement the known solution and instead sticks you with inefficient manual updating of every individual app.
you seem to think that webkit is the worse one here and that having for example a blink based or gecko based browser would means that these kind of bugs don’t happen.
that is unfortunately just wishful thinking. just read through the release notes of Chrome and Firefox and you will see that they all fix security bugs for every release.
all browser engines are of extremely high quality. but they also all keep having regular and security bugs.
If only one third of the users run a vulnerable browser, the other 2/3 would be safe. Security through compartmentalization.
> In early 2014, the European Parliament's Committee on Civil Liberties, Justice and Home Affairs released a draft report which confirmed that the intelligence agencies of New Zealand and Canada have cooperated with the NSA under the Five Eyes programme and may have been actively sharing the personal data of EU citizens. The EU report did not investigate if any international or domestic US laws were broken by the US and did not claim that any FVEY nation was illegally conducting intelligence collection on the EU.
For reference, this is the same NSA that has boasted about having inroads at companies like Google, Microsoft and Apple. The same FIVE EYES that recently "somehow" found the damning evidence to accuse India of conspiring to kill a foreign dissident.
Europe relies on America's surveillance network, and America's surveillance network relies on ___________.
A software monoculture means that a bug for one is a bug for all.
In short, you increase the possibilities, you increase the attack vectors. There is no way around it AFAIK.
Using the app at all is in the user's control. The current state of iOS is that they don't have any control whatsoever.
Not if it is mandated by work, home, family, government, etc.
So no, it is most definitely not in the user’s control.
> So no, it is most definitely not in the user’s control.
You're comparing impulse control to hard runtime limitations. It doesn't really track; I understand your apprehension, but if none of your family members notice or care then maybe Google's hypothetical solution here worked? If that's an undesirable outcome for you, I think you should be lobbying for better alternatives instead of using it as a boogeyman to excuse iron-grip ecosystems. Two wrongs aren't going to make a right here.
That's true, but the situation is not improved by a Chromium/Blink monoculture. It's the same problem with a slightly different flavor.
So yes, iOS should be opened to third party engines, but at the same time steps should be taken to stymy Chromium's dominance.
It is quite possible a native Chrome on iOS would be more secure.
Yes indeed, you’re still free not to use these apps. But would you? At some point why not get a computer where the internet is the “OS” (a chromebook for instance……… where guess what? you cannot use an alternate rendering engine. Interesting, no?)
Isn't that shoddy security architecture 101?
Browsers with sandboxed multi-process architectures have been around since 2008, precisely because experts realised that rendering engines are so complex they cannot reasonably be secured, so need to be sandboxed for protection.
Unfortunately, I suspect that security experts within Apple were well aware of this, but were overruled because iOS devices tend to not have much RAM, and the user experience would be severely degraded by doing proper process-per-origin isolation, due to RAM exhaustion.
If done well, it leads to a better comment-reading experience. Not sure I did it well in this example though.
I mean, this is not exactly shocking coming from the same company with "security experts" that released a version of macOS that allowed anybody to login to root with any password [1]. Their security review process is grossly incompetent. At some point you should stop believing the "security experts" who do the security equivalent of putting antifreeze into the ice cream because they ran out of sugar and the antifreeze tastes sweet so it must work just as well.
[1] https://arstechnica.com/information-technology/2017/11/macos...
> "Taking this approach a step further, Safari follows a simple one process per tab model, where two web- pages are never consolidated into the same rendering process, even under high memory pressure and even if they share an eTLD+1 in their URLs. Instead, Safari spawns a new rendering process for each tab until the system runs out of memory."
This suggests that Safari/Webkit is even more hardened in general. It's only in the context of `window.open()` that this isolation strategy is defeated. Notably, `window.open()` somewhat implies a shared context between the calling window and the newly opened one, since both windows receive a direct reference to the respective other one. I can't see any description, how other browser engines would handle this differently and would achieve perfect isolation, or, in case these were explored in similar depth, might yield similar vulnerabilities.
Unless you're using NoScript or something similar, you're doing just that right now.
The downside is that the web is a bit slower by default, but that might not necessarily be such a bad thing and encourage more developer consciousness of how much JS they're pulling in and how resource intensive it is.
I've been browsing that way for... oh, at least a year, probably more, and I don't notice a difference. The world isn't actually Javascript benchmarks (which suffer horribly, running the same hot loop over and over), and I seldom notice the performance difference.
It's just the default in my template for web browsing Qubes, along with disabling a few other things.
If you're on an Apple device, ignore Apple and enable Lockdown. You don't lose much (some image formats, occasionally this is annoying), and you gain serious robustness against a huge wave of attacks.
So actually it isn’t disabling JIT, it is making JIT opt-in.
You also lose custom fonts on sites, but that is more feature than bug these days.
Image: The famous JBIG2.
And only resumes executing when user clicks/touch some specific UI elements.
Browser should NOT be a generic application container. The browser was designed for "browsing" after all.
For websites, leaving the site auto signed-in seems the more practical way to exploit the vulnerability, so don’t leave sensitive site auto signed-in and use a native app for them instead is the natural way of mitigation?