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

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.

  When did you notify Apple?
  We disclosed our results to Apple on September 12, 2022 (408 days before public release).

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.

Good that they've added it. Disappointing to see that Apple has gone so long without releasing a fix.

> 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

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

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.

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

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: Seems like I got confused by the other very similar feature flag as well.

Edit: It appears I confused it with a similarly named flag. It doesn't appear to be enabled on macOS yet by default.

"Swap Processes on Cross-Site Navigation" is enabled by default, but this paper recommends "Swap Processes on Cross-Site Window Open".

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

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

Really interested to find out why Apple has (mostly) slept on this for over a year!

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.

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.

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.

defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1

Make sure your terminal has Full Disk Access and try again.

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.

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

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.

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

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.

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

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?

Clearly we need Vulnerability Website as-a-Service (VWaaS).

         .

Evidently they just get ignored, if their account of direct disclosure to Apple is anything to go off of.

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

This should be a reason to lift this policy and allow different engines on these devices!

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

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.

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.

Not if it is mandated by work, home, family, government, etc.

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.

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

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

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.

Isn't that shoddy security architecture 101?

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

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

Image: The famous JBIG2.

Video: https://en.wikipedia.org/wiki/Stagefright_(bug)

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.

Unless you're using NoScript or something similar, you're doing just that right now.