21 ms·

iLeakage: Browser-Based Timerless Speculative Execution Attacks on Apple Devices

611 points by aw1621107 3y ago

schmichael 3y ago
> We disclosed our results to Apple on September 12, 2022 (408 days before public release). Really interested to find out why Apple has (mostly) slept on this for over a year!
- KirillPanov 3y ago
  Because they can. 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.
  - semiquaver 3y ago
    BS. Being a CVE numbering authority (of which there are several hundred) does not grant a veto against CVE issuance. They are allowed to issue CVEs on their products but by no means are they the only authority that may issue them for Apple vulnerabilities.
    - viraptor 3y ago
      Also, you don't need to issue a CVE to publish a vulnerability. You just make it public regardless and say CVE was denied for it.
londons_explore 3y ago
So, Apple is letting secrets from one origin be in the same OS process as running code from another origin? Isn't that shoddy security architecture 101?
- londons_explore 3y ago
  Yes. Even without spectre, this would let anyone with any webkit exploit get secrets from any other website. 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.
  - pvg 3y ago
    That is a rather odd self-socratic method of commenting.
    - londons_explore 3y ago
      I usually do it because I want to pose a question and then give one viewpoint of answer to that question, while leaving the floor open to other viewpoints/opinions. If done well, it leads to a better comment-reading experience. Not sure I did it well in this example though.
      - npunt 3y ago
        I like the style, your comment created a clear train of thought and context
      - pvg 3y ago
        It ends up looking like sockpuppetry gone wrong and I think it kind of gives you an excuse to pose the opening question in a (however inadvertent) flameframy, scarecrowy way.
      - deleted 3y ago
        [deleted]
        deleted 3y ago
        [deleted]
- deleted 3y ago
  [deleted]
- masswerk 3y ago
  I'm not entirely sure about this. The paper mentions that in Chrome and Firefox "different rendering processes handle pages with different effective top-level domain plus one sub-domain (eTLD+1)." (Meaning, windows in the same eTLD+1 group still share a process.) To proceed, > "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.
- deleted 3y ago
  [deleted]
az09mugen 3y ago
Please Apple, stop supporting safari, even edge is a better browser
Belopolye 3y ago
> However, this mitigation is not enabled by default, and enabling it is possible only on macOS. Is this not covered by lockdown mode on iOS? Crazy.
- fh9302 3y ago
  The paper mentions JIT multiple times, lockdown mode disables JIT. I hope someone else can confirm it but it appears it would be mitigated in this case.
  - kevincox 3y ago
    It seems like JIT would make the attack easier as faster code will get more accurate timings but it doesn't seem to really stop the attack.
    - saagarjha 3y ago
      It's not just faster code, but also having more control over it. The JIT engine is more than happy to put a hundred data-dependent instructions right after each other; an interpreter makes this harder.
Flockster 3y ago
> However, iOS has a different situation. Due to Apple's App Store and sandboxing policies, other browser apps are forced to use Safari's JavaScript engine. That is, Chrome, Firefox and Edge on iOS are simply wrappers on top of Safari that provide auxiliary features such as synchronizing bookmarks and settings. Consequently, nearly every browser application listed on the App Store is vulnerable to iLeakage. This should be a reason to lift this policy and allow different engines on these devices!
- fsflover 3y ago
  But it's for your security! Not joking: https://news.ycombinator.com/item?id=21587191 https://news.ycombinator.com/item?id=21587191
  - paulmd 3y ago
    unironically, having three browser engines is three times the attack surface, what's the problem with that claim? 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?
cedws 3y ago
I'm confused. This seems like a high severity issue, but the fix is behind a debug menu? Why has this been made public before a fix has been properly rolled out everywhere? 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.
- fh9302 3y ago
  It's unclear if they even reported this issue to Apple.
  - cedws 3y ago
    It's been reported >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.
    - DannyBee 3y ago
      Look at the faq
      - cedws 3y ago
        See edit.
  - HatchedLake721 3y ago
    Interestingly, the YouTube videos are 13 months old.
    - thfuran 3y ago
      That's when they reported it to apple.
  - matthewdgreen 3y ago
jeroenhd 3y ago
Things I'm missing from this FAQ: - 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).
- mdeeks 3y ago
  They have an answer to your last question in the FAQ When did you notify Apple? We disclosed our results to Apple on September 12, 2022 (408 days before public release).
  - jeroenhd 3y ago
    That wasn't on the page when I read it. Good that they've added it. Disappointing to see that Apple has gone so long without releasing a fix.
    - deleted 3y ago
      [deleted]
  - fh9302 3y ago
    They added this FAQ point a couple minutes ago, that's why the existing comments didn't see it.
  - mgiampapa 3y ago
    408 days and it still requires a user to enable via a debug menu? This is not a good security look from apple.
    - fguerraz 3y ago
      I don’t know why they make it an Apple problem. They claim their attack works on all browsers, and it doesn’t look like it’s fixed on any of them.
exabrial 3y ago
So what we've learned once again is: running random code off of the internet is a bad idea... Wonder if we'll stop doing this at some point?
- deleted 3y ago
  [deleted]
- HideousKojima 3y ago
  Hit F12. Unless you're using NoScript or something similar, you're doing just that right now.
  - i_love_cookies 3y ago
    [dead]
- jwells89 3y ago
  To me the danger seems to be not in the randomness of the code, but that it can run without the user's prompting or consent. Perhaps it would be a good idea for browsers to disable JS JIT by default (as this is where a large percentage of holes crop up) and allow the user to enable it where they find the benefit low-risk and worthwhile (e.g. with vetted web apps). 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.
  - Syonyk 3y ago
    Just disable JIT and WASM. 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.
sroussey 3y ago
window.open() strikes again
- fh9302 3y ago
  Does this mean you would have to visit a malicious website, that malicious website would open a different website with window.open(), and from this they can read data through this side channel attack?
  - jeroenhd 3y ago
    That seems to be the implication of this attack. The mitigation referenced by the web page are being rolled out in newer versions of Safari and iOS, according to other comments in these threads. 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.
  - paulirish 3y ago
    Yes. But it's incredibly hard to pull off. 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://w3c.github.io/webappsec-post-spectre-webdev/ https://www.chromium.org/Home/chromium-security/site-isolation/ https://www.chromium.org/Home/chromium-security/site-isolati... https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html https://blog.chromium.org/2021/03/mitigating-side-channel-at...
drvdevd 3y ago
From a cursory review of the FAQs on the page it appears one mitigation might be to only keep one browser tab open at a time? They appear to be using timers and a cache eviction gadget to infer the state of other browser tabs/processes so it’s unclear what they can recover if you are not concurrently having a session to a particular site outside the gadget execution context. ???
- lights0123 3y ago
  They use window.open on a mouseover event listener to open another page. Even if you close it, they still are able to read from it as that memory isn't immediately zeroed or returned to the OS.
  - deleted 3y ago
    [deleted]
- missblit 3y ago
  Besides windows.open I'd wonder if iframes could also be vulnerable if they launch in the same process. 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-site-isolation-security-architecture/ https://hacks.mozilla.org/2021/05/introducing-firefox-new-si...
masswerk 3y ago
Please correct me, if I'm misinterpreting this, but is the framing regarding Webkit-only actually correct? The cache exploit seems to be a general one: > 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?
- deleted 3y ago
  [deleted]
  - deleted 3y ago
    [deleted]
- mccr8 3y ago
  Chromium and Firefox have implemented site isolation on their desktop browsers, so pages that are not same site should never be loaded in the same process. On mobile browsers, Chromium's site isolation is limited, and Firefox has not finished implementing it. https://www.chromium.org/Home/chromium-security/site-isolation/ https://www.chromium.org/Home/chromium-security/site-isolati...
  - masswerk 3y ago
    Notably, the paper suggests that Webkit is even more hardened: > 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?
wutwutwat 3y ago
What is the point of the dedicated vulnerability marketing websites? Like, for real, why do people buy a domain, configure dns, design a full webpage, setup some server somewhere? 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
- saagarjha 3y ago
  It's because when a news website wants to talk about the vulnerability they get a webpage to link to that is canonical and has all the information someone would want to get an accurate description of the issue.
  - wutwutwat 3y ago
    Isn't that exactly what https://www.cve.org/ https://www.cve.org/ would be for?
    - HtmlProgrammer 3y ago
      Yes
    - saagarjha 3y ago
      No, that's the place where you get an identifier for the issue. You still need a place with answers to frequently asked questions, more details as to how the attack works, artifacts and proof-of-concept code, etc.
      - wutwutwat 3y ago
        CVE's usually link to the SCM issue/pull request where the conversation, and reproduction takes place. We've been finding and patching vulnerabilities for decades without the need for dedicated websites to inform folks, so that reason for these sites needing to exist doesn't make any sense.
jesseendahl 3y ago
>Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers. Can't wait for passkeys to replace passwords everywhere.
zenlambda 3y ago
I thought I had seen a mention of a fix on the ileakage website and then it dissapeared. I almost thought I imagined the whole thing, but actually they have been making changes to the website only in the past hour. > "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.io/commit/eed4e26553a203a0cd488a3a22846c5c1060eb33 https://github.com/ileakage-authors/ileakage-authors.github....
- cedws 3y ago
  I think one of the authors of the paper are reading this thread because when I pointed out that there was no timeline on the site, they added a brief section to the FAQ. There is also some confusion here about whether a fix has been rolled out so I think they've also become confused.
- kuhsaft 3y ago
  Strange. I’ve updated to iOS 17.1 and under Settings -> Safari -> Advanced -> Feature Flags, the `Swap Processes on Cross-Site Navigation` is there and is enabled by default. I wonder if it’s different from `Swap Processes on Cross-Site Window Open` on macOS.
  - st3fan 3y ago
    also on by default on 17.0.3. i definitely did not change this.
  - t-sauer 3y ago
    It is different. The cross-site navigation flag is a couple of years old. It was enabled by default for iOS in November 2018 for example https://github.com/WebKit/WebKit/commit/e191fc8c412850cb9fd0c2ab88874ad981dae012 https://github.com/WebKit/WebKit/commit/e191fc8c412850cb9fd0...
pwdisswordfishc 3y ago
Why does a website about a security vulnerability in a JavaScript engine sabotage the security mitigation of disabling JavaScript, by requiring it for collapsible sections? As if they couldn't just use <details>.
- autoexec 3y ago
  No joke! It's amazing how much better protected you are by not allowing javascript and other active content by default but websites are dead set against letting people do that without massive inconvenience because for some reason displaying even basic text and images has become unthinkable without requiring a bunch of third party remotely hosted JS
- deleted 3y ago
  [deleted]
jeron 3y ago
> 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. as a rare Intel Mac owner, I guess I am not affected then
- lern_too_spel 3y ago
  If you're on MacOS, you can simply not use Safari. If you're on iOS, you have to use lockdown mode, which is the only safe way to use an iPhone. Any benchmarks done without lockdown mode should be considered as useful as CPU benchmarks run with mitigations=off.
  - worthless-trash 3y ago
    Can you link to me where lockdown mode would prevent this kind of attack ?
  - kevincox 3y ago
    That's absolutely not fair. Lockdown mode isn't the default and should only provide defense in depth. Devices running the default configuration are absolutely expected to be secure.
    - lern_too_spel 3y ago
      > Devices running the default configuration are absolutely expected to be secure. 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.
      - brookst 3y ago
        Nothing in the world is 100% secure; there are tradeoffs. Lockdown mode is more secure (but certainly not 100% secure) at the expense of less usable and less performant. Demanding absolute security on the default configuration is unreasonable. No platform provides that.
Kiboneu 3y ago
The website says that you can enable the “Swap Processes on Cross-Site Navigation” flag only on macos; actually on iOS you can access this flag via Settings -> Safari -> Advanced -> Feature Flags. I think this is the ios equivalent to the macos mitigation that the authors are suggesting.
- thoughtsimple 3y ago
  It also seems to be on by default on iOS 17.1. It doesn't seem to on by default in MacOS Sonoma (14.1).
- jacopoj 3y ago
  That's a different flag. The website says you should enable "Swap Processes on Cross-Site Window Open"
ceva 3y ago
Interesting
codezero 3y ago
If you're getting an error when trying to run: defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1 Make sure your terminal has Full Disk Access and try again.
Aloha 3y ago
> Am I at risk if I use a credential manager? > 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.
- NobodyNada 3y ago
  I think they’re saying that you’re not more vulnerable with a password manager than you would be without one. I.e. they can recover passwords that have been autofilled into a page, just as if you entered the password manually, but they can’t read all your stored passwords directly out of your password manager.
  - Aloha 3y ago
    That doesn't jive to me with my read of their text.
    - gumby 3y ago
      FWIW I read it the same as the others.
- borski 3y ago
  They're basically saying: a) you are safer with a password manager than without, in general, despite it not providing any additional security for this particular attack; it is also not any more vulnerable. having a password manager doesn't make you more likely to be caught by this attack (because the last thing they want to do is accidentally convince people to stop using them, in favor of 'newpassword2') b) you are safer yet if you turn off automatic autofill and instead use a hotkey or some other form of user interaction
- 3y ago
ngneer 3y ago
"We note that iLeakage is a significantly difficult attack to orchestrate end-to-end, and requires advanced knowledge of browser-based side-channel attacks and Safari's implementation" - possibly the reason Apple is not losing sleep over this?
- BearOso 3y ago
  So difficult to orchestrate that it's unfeasible, so there's effectively 0% risk involved. Yet another scary nickname and domain name for it says unprofessional and untrustworthy to me.
  - saagarjha 3y ago
    The sophistication of the authors in their paper speaks to the opposite. Give it a read!
  - viraptor 3y ago
    It's been shown possible, so: 1. There's a number of well funded agencies which would be happy to abuse it. They have both the skills and time to do it. 2. Showing that Spectre is possible on Intel created a steady stream of similar attacks. Other groups are likely already looking into it and may come up with much more feasible options.
  - userbinator 3y ago
    The security industry runs on fear, so that's not so surprising. 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.
    - worthless-trash 3y ago
      Eh, If an average security programmer redneck like myself can abuse spectre and meltdown, I am pretty sure that some of the malware/ransomware can, they are not state sponsored but do have a financial incentive to do so. An attack vector is available, they'll abuse it if they can. Do you think I'm overestimating them ?
darkclouds 3y ago
[dead]
avodonosov 3y ago
It must be time consuming to read other process' memory through such a side channel. Then limiting JS execution time for web pages should mitigate this vulnerability? 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 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.
- piperswe 3y ago
  This will likely just fatigue users, who will just keep tapping "yes" on the prompts to make the websites work.
  - userbinator 3y ago
    The point is that most sites don't need that much intense JS processing. Also, a "no, and don't ask again" button would be very useful in this case.
    - InsomniacL 3y ago
      The end-user would have no idea if that much JS processing is legitimately required or not. "no, and don't ask again" would cause no-end of support issues.
      - avodonosov 3y ago
        I know one end-user who would very much want a browser setting for default compute limit for domains / pages, after which browser will start asking confirmation, as described in the above comments. Web pages could also ask for such permission upfront, using e.g. a Meta tag. Such a setting whould also reduce malicious crypto mining possibilities.
sinuhe69 3y ago
All auto-password filling on iOS requires 2FA so Apple doesn’t have to fear or how it’s to explain that Apple hasn’t mitigated this attack vector yet? 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?
archo 3y ago
Is this mitigated with 25 oct updates https://support.apple.com/en-au/HT201222 https://support.apple.com/en-au/HT201222
est 3y ago
Javascript should stop executing after body.load. 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.
- deleted 3y ago
  [deleted]
timvisee 3y ago
Another good reason to allow other browser engines on iOS devices.
- Yeul 3y ago
  EU regulations may eventually force Apple.
Razengan 3y ago
I just want to say how comically bizarre the whole OS/Browser dichotomy/duplication has become.
allan_s 3y ago
I don't know how to point out an improvement > 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"
- vinay427 3y ago
  At least for me, this was caused by a OS security permission: enabling Full Disk Access for the terminal emulator app in Security & Privacy (System Preferences) fixed it for me and the setting can obviously be reverted afterwards.
thepasswordguy 3y ago
Another reason I use uBlock Origin to block Javascript by default, and why I don't use a password manager that autofills without user intervention.

611 points by aw1621107 3y ago

> We disclosed our results to Apple on September 12, 2022 (408 days before public release). Really interested to find out why Apple has (mostly) slept on this for over a year!

KirillPanov 3y ago
Because they can. 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.
- semiquaver 3y ago
  BS. Being a CVE numbering authority (of which there are several hundred) does not grant a veto against CVE issuance. They are allowed to issue CVEs on their products but by no means are they the only authority that may issue them for Apple vulnerabilities.
  - viraptor 3y ago
    Also, you don't need to issue a CVE to publish a vulnerability. You just make it public regardless and say CVE was denied for it.

londons_explore 3y ago

So, Apple is letting secrets from one origin be in the same OS process as running code from another origin? Isn't that shoddy security architecture 101?

londons_explore 3y ago
Yes. Even without spectre, this would let anyone with any webkit exploit get secrets from any other website. 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.
- pvg 3y ago
  That is a rather odd self-socratic method of commenting.
  - londons_explore 3y ago
    I usually do it because I want to pose a question and then give one viewpoint of answer to that question, while leaving the floor open to other viewpoints/opinions. If done well, it leads to a better comment-reading experience. Not sure I did it well in this example though.
    - npunt 3y ago
      I like the style, your comment created a clear train of thought and context
    - pvg 3y ago
      It ends up looking like sockpuppetry gone wrong and I think it kind of gives you an excuse to pose the opening question in a (however inadvertent) flameframy, scarecrowy way.
    - deleted 3y ago
      [deleted]
      - deleted 3y ago
        [deleted]
deleted 3y ago
[deleted]
masswerk 3y ago
I'm not entirely sure about this. The paper mentions that in Chrome and Firefox "different rendering processes handle pages with different effective top-level domain plus one sub-domain (eTLD+1)." (Meaning, windows in the same eTLD+1 group still share a process.) To proceed, > "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.
deleted 3y ago
[deleted]

az09mugen 3y ago

Please Apple, stop supporting safari, even edge is a better browser

Belopolye 3y ago

> However, this mitigation is not enabled by default, and enabling it is possible only on macOS. Is this not covered by lockdown mode on iOS? Crazy.

fh9302 3y ago
The paper mentions JIT multiple times, lockdown mode disables JIT. I hope someone else can confirm it but it appears it would be mitigated in this case.
- kevincox 3y ago
  It seems like JIT would make the attack easier as faster code will get more accurate timings but it doesn't seem to really stop the attack.
  - saagarjha 3y ago
    It's not just faster code, but also having more control over it. The JIT engine is more than happy to put a hundred data-dependent instructions right after each other; an interpreter makes this harder.

Flockster 3y ago

> However, iOS has a different situation. Due to Apple's App Store and sandboxing policies, other browser apps are forced to use Safari's JavaScript engine. That is, Chrome, Firefox and Edge on iOS are simply wrappers on top of Safari that provide auxiliary features such as synchronizing bookmarks and settings. Consequently, nearly every browser application listed on the App Store is vulnerable to iLeakage. This should be a reason to lift this policy and allow different engines on these devices!

fsflover 3y ago
But it's for your security! Not joking: https://news.ycombinator.com/item?id=21587191 https://news.ycombinator.com/item?id=21587191
- paulmd 3y ago
  unironically, having three browser engines is three times the attack surface, what's the problem with that claim? 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?

cedws 3y ago

I'm confused. This seems like a high severity issue, but the fix is behind a debug menu? Why has this been made public before a fix has been properly rolled out everywhere? 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.

fh9302 3y ago
It's unclear if they even reported this issue to Apple.
- cedws 3y ago
  It's been reported >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.
  - DannyBee 3y ago
    Look at the faq
    - cedws 3y ago
      See edit.
- HatchedLake721 3y ago
  Interestingly, the YouTube videos are 13 months old.
  - thfuran 3y ago
    That's when they reported it to apple.
- matthewdgreen 3y ago

jeroenhd 3y ago

Things I'm missing from this FAQ: - 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).

mdeeks 3y ago
They have an answer to your last question in the FAQ When did you notify Apple? We disclosed our results to Apple on September 12, 2022 (408 days before public release).
- jeroenhd 3y ago
  That wasn't on the page when I read it. Good that they've added it. Disappointing to see that Apple has gone so long without releasing a fix.
  - deleted 3y ago
    [deleted]
- fh9302 3y ago
  They added this FAQ point a couple minutes ago, that's why the existing comments didn't see it.
- mgiampapa 3y ago
  408 days and it still requires a user to enable via a debug menu? This is not a good security look from apple.
  - fguerraz 3y ago
    I don’t know why they make it an Apple problem. They claim their attack works on all browsers, and it doesn’t look like it’s fixed on any of them.

exabrial 3y ago

So what we've learned once again is: running random code off of the internet is a bad idea... Wonder if we'll stop doing this at some point?

deleted 3y ago
[deleted]
HideousKojima 3y ago
Hit F12. Unless you're using NoScript or something similar, you're doing just that right now.
- i_love_cookies 3y ago
  [dead]
jwells89 3y ago
To me the danger seems to be not in the randomness of the code, but that it can run without the user's prompting or consent. Perhaps it would be a good idea for browsers to disable JS JIT by default (as this is where a large percentage of holes crop up) and allow the user to enable it where they find the benefit low-risk and worthwhile (e.g. with vetted web apps). 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.
- Syonyk 3y ago
  Just disable JIT and WASM. 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.

sroussey 3y ago

window.open() strikes again

fh9302 3y ago
Does this mean you would have to visit a malicious website, that malicious website would open a different website with window.open(), and from this they can read data through this side channel attack?
- jeroenhd 3y ago
  That seems to be the implication of this attack. The mitigation referenced by the web page are being rolled out in newer versions of Safari and iOS, according to other comments in these threads. 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.
- paulirish 3y ago
  Yes. But it's incredibly hard to pull off. 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://w3c.github.io/webappsec-post-spectre-webdev/ https://www.chromium.org/Home/chromium-security/site-isolation/ https://www.chromium.org/Home/chromium-security/site-isolati... https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html https://blog.chromium.org/2021/03/mitigating-side-channel-at...

drvdevd 3y ago

From a cursory review of the FAQs on the page it appears one mitigation might be to only keep one browser tab open at a time? They appear to be using timers and a cache eviction gadget to infer the state of other browser tabs/processes so it’s unclear what they can recover if you are not concurrently having a session to a particular site outside the gadget execution context. ???

lights0123 3y ago
They use window.open on a mouseover event listener to open another page. Even if you close it, they still are able to read from it as that memory isn't immediately zeroed or returned to the OS.
- deleted 3y ago
  [deleted]
missblit 3y ago
Besides windows.open I'd wonder if iframes could also be vulnerable if they launch in the same process. 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-site-isolation-security-architecture/ https://hacks.mozilla.org/2021/05/introducing-firefox-new-si...

masswerk 3y ago

Please correct me, if I'm misinterpreting this, but is the framing regarding Webkit-only actually correct? The cache exploit seems to be a general one: > 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?

deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
mccr8 3y ago
Chromium and Firefox have implemented site isolation on their desktop browsers, so pages that are not same site should never be loaded in the same process. On mobile browsers, Chromium's site isolation is limited, and Firefox has not finished implementing it. https://www.chromium.org/Home/chromium-security/site-isolation/ https://www.chromium.org/Home/chromium-security/site-isolati...
- masswerk 3y ago
  Notably, the paper suggests that Webkit is even more hardened: > 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?

wutwutwat 3y ago

What is the point of the dedicated vulnerability marketing websites? Like, for real, why do people buy a domain, configure dns, design a full webpage, setup some server somewhere? 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

saagarjha 3y ago
It's because when a news website wants to talk about the vulnerability they get a webpage to link to that is canonical and has all the information someone would want to get an accurate description of the issue.
- wutwutwat 3y ago
  Isn't that exactly what https://www.cve.org/ https://www.cve.org/ would be for?
  - HtmlProgrammer 3y ago
    Yes
  - saagarjha 3y ago
    No, that's the place where you get an identifier for the issue. You still need a place with answers to frequently asked questions, more details as to how the attack works, artifacts and proof-of-concept code, etc.
    - wutwutwat 3y ago
      CVE's usually link to the SCM issue/pull request where the conversation, and reproduction takes place. We've been finding and patching vulnerabilities for decades without the need for dedicated websites to inform folks, so that reason for these sites needing to exist doesn't make any sense.

jesseendahl 3y ago

>Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers. Can't wait for passkeys to replace passwords everywhere.

zenlambda 3y ago

I thought I had seen a mention of a fix on the ileakage website and then it dissapeared. I almost thought I imagined the whole thing, but actually they have been making changes to the website only in the past hour. > "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.io/commit/eed4e26553a203a0cd488a3a22846c5c1060eb33 https://github.com/ileakage-authors/ileakage-authors.github....

cedws 3y ago
I think one of the authors of the paper are reading this thread because when I pointed out that there was no timeline on the site, they added a brief section to the FAQ. There is also some confusion here about whether a fix has been rolled out so I think they've also become confused.
kuhsaft 3y ago
Strange. I’ve updated to iOS 17.1 and under Settings -> Safari -> Advanced -> Feature Flags, the `Swap Processes on Cross-Site Navigation` is there and is enabled by default. I wonder if it’s different from `Swap Processes on Cross-Site Window Open` on macOS.
- st3fan 3y ago
  also on by default on 17.0.3. i definitely did not change this.
- t-sauer 3y ago
  It is different. The cross-site navigation flag is a couple of years old. It was enabled by default for iOS in November 2018 for example https://github.com/WebKit/WebKit/commit/e191fc8c412850cb9fd0c2ab88874ad981dae012 https://github.com/WebKit/WebKit/commit/e191fc8c412850cb9fd0...

pwdisswordfishc 3y ago

Why does a website about a security vulnerability in a JavaScript engine sabotage the security mitigation of disabling JavaScript, by requiring it for collapsible sections? As if they couldn't just use <details>.

autoexec 3y ago
No joke! It's amazing how much better protected you are by not allowing javascript and other active content by default but websites are dead set against letting people do that without massive inconvenience because for some reason displaying even basic text and images has become unthinkable without requiring a bunch of third party remotely hosted JS
deleted 3y ago
[deleted]

jeron 3y ago

> 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. as a rare Intel Mac owner, I guess I am not affected then

lern_too_spel 3y ago
If you're on MacOS, you can simply not use Safari. If you're on iOS, you have to use lockdown mode, which is the only safe way to use an iPhone. Any benchmarks done without lockdown mode should be considered as useful as CPU benchmarks run with mitigations=off.
- worthless-trash 3y ago
  Can you link to me where lockdown mode would prevent this kind of attack ?
- kevincox 3y ago
  That's absolutely not fair. Lockdown mode isn't the default and should only provide defense in depth. Devices running the default configuration are absolutely expected to be secure.
  - lern_too_spel 3y ago
    > Devices running the default configuration are absolutely expected to be secure. 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.
    - brookst 3y ago
      Nothing in the world is 100% secure; there are tradeoffs. Lockdown mode is more secure (but certainly not 100% secure) at the expense of less usable and less performant. Demanding absolute security on the default configuration is unreasonable. No platform provides that.

Kiboneu 3y ago

The website says that you can enable the “Swap Processes on Cross-Site Navigation” flag only on macos; actually on iOS you can access this flag via Settings -> Safari -> Advanced -> Feature Flags. I think this is the ios equivalent to the macos mitigation that the authors are suggesting.

thoughtsimple 3y ago
It also seems to be on by default on iOS 17.1. It doesn't seem to on by default in MacOS Sonoma (14.1).
jacopoj 3y ago
That's a different flag. The website says you should enable "Swap Processes on Cross-Site Window Open"

ceva 3y ago

Interesting

codezero 3y ago

If you're getting an error when trying to run: defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1 Make sure your terminal has Full Disk Access and try again.

Aloha 3y ago

> Am I at risk if I use a credential manager? > 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.

NobodyNada 3y ago
I think they’re saying that you’re not more vulnerable with a password manager than you would be without one. I.e. they can recover passwords that have been autofilled into a page, just as if you entered the password manually, but they can’t read all your stored passwords directly out of your password manager.
- Aloha 3y ago
  That doesn't jive to me with my read of their text.
  - gumby 3y ago
    FWIW I read it the same as the others.
borski 3y ago
They're basically saying: a) you are safer with a password manager than without, in general, despite it not providing any additional security for this particular attack; it is also not any more vulnerable. having a password manager doesn't make you more likely to be caught by this attack (because the last thing they want to do is accidentally convince people to stop using them, in favor of 'newpassword2') b) you are safer yet if you turn off automatic autofill and instead use a hotkey or some other form of user interaction
3y ago

ngneer 3y ago

"We note that iLeakage is a significantly difficult attack to orchestrate end-to-end, and requires advanced knowledge of browser-based side-channel attacks and Safari's implementation" - possibly the reason Apple is not losing sleep over this?

BearOso 3y ago
So difficult to orchestrate that it's unfeasible, so there's effectively 0% risk involved. Yet another scary nickname and domain name for it says unprofessional and untrustworthy to me.
- saagarjha 3y ago
  The sophistication of the authors in their paper speaks to the opposite. Give it a read!
- viraptor 3y ago
  It's been shown possible, so: 1. There's a number of well funded agencies which would be happy to abuse it. They have both the skills and time to do it. 2. Showing that Spectre is possible on Intel created a steady stream of similar attacks. Other groups are likely already looking into it and may come up with much more feasible options.
- userbinator 3y ago
  The security industry runs on fear, so that's not so surprising. 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.
  - worthless-trash 3y ago
    Eh, If an average security programmer redneck like myself can abuse spectre and meltdown, I am pretty sure that some of the malware/ransomware can, they are not state sponsored but do have a financial incentive to do so. An attack vector is available, they'll abuse it if they can. Do you think I'm overestimating them ?

darkclouds 3y ago

[dead]

avodonosov 3y ago

It must be time consuming to read other process' memory through such a side channel. Then limiting JS execution time for web pages should mitigate this vulnerability? 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 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.

piperswe 3y ago
This will likely just fatigue users, who will just keep tapping "yes" on the prompts to make the websites work.
- userbinator 3y ago
  The point is that most sites don't need that much intense JS processing. Also, a "no, and don't ask again" button would be very useful in this case.
  - InsomniacL 3y ago
    The end-user would have no idea if that much JS processing is legitimately required or not. "no, and don't ask again" would cause no-end of support issues.
    - avodonosov 3y ago
      I know one end-user who would very much want a browser setting for default compute limit for domains / pages, after which browser will start asking confirmation, as described in the above comments. Web pages could also ask for such permission upfront, using e.g. a Meta tag. Such a setting whould also reduce malicious crypto mining possibilities.

sinuhe69 3y ago

All auto-password filling on iOS requires 2FA so Apple doesn’t have to fear or how it’s to explain that Apple hasn’t mitigated this attack vector yet? 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?

archo 3y ago

Is this mitigated with 25 oct updates https://support.apple.com/en-au/HT201222 https://support.apple.com/en-au/HT201222

est 3y ago

Javascript should stop executing after body.load. 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.

deleted 3y ago
[deleted]

timvisee 3y ago

Another good reason to allow other browser engines on iOS devices.

Yeul 3y ago
EU regulations may eventually force Apple.

Razengan 3y ago

I just want to say how comically bizarre the whole OS/Browser dichotomy/duplication has become.

allan_s 3y ago

I don't know how to point out an improvement > 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"

vinay427 3y ago
At least for me, this was caused by a OS security permission: enabling Full Disk Access for the terminal emulator app in Security & Privacy (System Preferences) fixed it for me and the setting can obviously be reverted afterwards.

thepasswordguy 3y ago

Another reason I use uBlock Origin to block Javascript by default, and why I don't use a password manager that autofills without user intervention.