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.
> Why has this been made public before a fix has been properly rolled out everywhere?
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.
I'm as confused about the mitigation status as others. However, the paper is clearer than the website:
> 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].
For standard Safari (not technology preview) 17.0 on Ventura "Swap Processes on Cross-Site Window Open" is already enabled (and labeled Stable) for me. I did not enable it so it's possible Apple already enabled this and their description of how to enable etc. is out of date.
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.
> Why has this been made public before a fix has been properly rolled out everywhere?
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.
> This seems like a high severity issue, but the fix is behind a debug menu?
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.
They reported it to Apple a long time ago, over a year I think. The problem appears to be that it's very hard to mitigate.
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.
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.