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

Things I&#x27;m missing from this FAQ:<p>- Is this a Webkit vulnerability or a Safari vulnerability?<p>- Does enabling Lockdown mode mitigate this vulnerability, seeing as mobile Safari doesn&#x27;t expose these dev settings?<p>- What&#x27;s the timeline on the disclosure to Apple?<p>Edit: they updated the page to answer the last question:<p><pre><code> When did you notify Apple? We disclosed our results to Apple on September 12, 2022 (408 days before public release).</code></pre>

&gt; Am I at risk if I use a credential manager?<p>&gt; 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.<p>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&#x27;m not familiar enough in this area to understand this caveat.

Please correct me, if I&#x27;m misinterpreting this, but is the framing regarding Webkit-only actually correct? The cache exploit seems to be a general one:<p>&gt; <i>Here, we show that our attacks have near perfect accuracy across Safari, Firefox, and Tor.</i><p>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?

I&#x27;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?<p>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.

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

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.<p>&gt; &quot;To mitigate our work, Apple has just released iOS 17.1, iPadOS 17.1, and macOS Sonoma 14.1. Update your devices now!&quot;<p>Which they have now reverted.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;ileakage-authors&#x2F;ileakage-authors.github.io&#x2F;commit&#x2F;eed4e26553a203a0cd488a3a22846c5c1060eb33">https:&#x2F;&#x2F;github.com&#x2F;ileakage-authors&#x2F;ileakage-authors.github....</a>

&quot;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&#x27;s implementation&quot; - possibly the reason Apple is not losing sleep over this?

&gt; if you have a device running macOS or iOS with Apple&#x27;s A-series or M-series CPUs. This includes all recent iPhones and iPads, as well as Apple&#x27;s laptops and desktops from 2020 and onwards.<p>as a rare Intel Mac owner, I guess I am not affected then

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

If you&#x27;re getting an error when trying to run:<p>defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1<p>Make sure your terminal has Full Disk Access and try again.

It must be time consuming to read other process&#x27; memory through such a side channel. Then limiting JS execution time for web pages should mitigate this vulnerability?<p>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&#x27;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.<p>Upd: 4-5 minutes, in the first video (<a href="https:&#x2F;&#x2F;youtu.be&#x2F;Z2RtpN77H8o?si=XB4oI9ner8pFTIqN" rel="nofollow noreferrer">https:&#x2F;&#x2F;youtu.be&#x2F;Z2RtpN77H8o?si=XB4oI9ner8pFTIqN</a>) - see the time on the top right of their screen. When the attack starts it&#x27;s 5:22, ends at 5:27.

&gt;Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers.<p>Can&#x27;t wait for passkeys to replace passwords everywhere.

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&#x2F;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. ???

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

I don&#x27;t know how to point out an improvement<p>&gt; defaults write com.apple.Safari IncludeInternalDebugMenu 1.<p>if you get<p>&gt; Could not write domain &#x2F;Users&#x2F;YourUser&#x2F;Library&#x2F;Containers&#x2F;com.apple.Safari&#x2F;Data&#x2F;Library&#x2F;Preferences&#x2F;com.apple.Safari; exiting<p>instead you can check in the &quot;develop&quot; menu of safari , and section &quot;feature flags&quot;

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 -&gt; Safari -&gt; Advanced -&gt; Feature Flags. I think this is the ios equivalent to the macos mitigation that the authors are suggesting.

Is this mitigated with 25 oct updates <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-au&#x2F;HT201222" rel="nofollow noreferrer">https:&#x2F;&#x2F;support.apple.com&#x2F;en-au&#x2F;HT201222</a>

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

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

I just want to say how comically bizarre the whole OS&#x2F;Browser dichotomy&#x2F;duplication has become.

window.open() strikes again

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?<p>Is there some secret world I don&#x27;t know about that&#x27;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.<p>Can someone explain this to me because I feel like I&#x27;m missing something. Just feels like peak consumerism and attention economy bs that shouldn&#x27;t be needed imo, but I hope I&#x27;m missing some crucial thing that makes these valid

&gt; However, iOS has a different situation. Due to Apple&#x27;s App Store and sandboxing policies, other browser apps are forced to use Safari&#x27;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.<p>This should be a reason to lift this policy and allow different engines on these devices!

So, Apple is letting secrets from one origin be in the same OS process as running code from another origin?<p>Isn&#x27;t that shoddy security architecture 101?

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

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&#x27;t just use &lt;details&gt;.

Javascript should stop executing after body.load.<p>And only resumes executing when user clicks&#x2F;touch some specific UI elements.<p>Browser should NOT be a generic application container. The browser was designed for &quot;browsing&quot; after all.

Interesting

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