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