3 ms·

> We disclosed our results to Apple on May 24, 2024. Apple’s Product Security Team have acknowledged our report and proof-of-concept code, requesting an extende

> We disclosed our results to Apple on May 24, 2024. Apple’s Product Security Team have acknowledged our report and proof-of-concept code, requesting an extended embargo beyond the 90-day window. At the time of writing, Apple did not share any schedule regarding mitigation plans concerning the results presented in this paper. The vulnerability is over half a year old and over a quarter over the embargo window.

sofixa 2y ago
I wonder if Apple are being slow due to the complexity of the potential fix, or because they're dragging their feet.
- kllrnohj 2y ago
  Or it's a hardware issue and they don't have any way to do a microcode fix for this
  - sebzim4500 2y ago
    It's could be unfixable without a significant performance penalty, but at minimum they could make safari do proper process isolation like every other browser does.
    - School-Cotton 2y ago
      I could easily imagine such a refactor of Safari taking more than 90 days even if Apple made it the highest possible priority.
      - goldsteinq 2y ago
        The bug is open since 2018, so clearly they don’t actually care about that. https://bugs.webkit.org/show_bug.cgi?id=184466 https://bugs.webkit.org/show_bug.cgi?id=184466
        School-Cotton 2y ago
        Right, but that was before they knew about this exploit. My point was that even if they decided they needed to urgently switch to a multiprocesses architecture because it's the only way to mitigate this exploit, they might not be done yet.
        goldsteinq 2y ago
        This class of attacks is not new. Spectre demonstrated this possibility in 2018, and Apple was previously targeted by speculation attacks, e.g. https://gofetch.fail/ https://gofetch.fail/ or https://ileakage.com/ https://ileakage.com/.
- alt227 2y ago
  Because the fix will most likely kill performance, like Spectre/Meltdown did, and then their pretty graphs wont look so impressive any more.
- latexr 2y ago
  As someone who has reported several (software) security vulnerabilities to Apple, I couldn’t care less. Some of the things I reported are trivial to fix, and dealing with their team has been a frustrating experience. They don’t deserve extensions, they need to get their shit together and stop releasing new crap every year. Clearly they can’t do it properly.
tptacek 2y ago
The LVP vulnerability was reported in September, for what it's worth.
- gabeio 2y ago
  That's still more or less 120 days ago. Well over the 90 day typical window.
  - tptacek 2y ago
    I'm not saying it's bad (I'm pretty close to a disclosure absolutist), though I don't really know what the norms are for hardware attacks --- both papers are well past the normal coordinated disclosure window for software.
    - hashstring 2y ago
      The vendor requested embargo timelines can get pretty crazy. Intel requested an embargo for 21 months for SRBDS/Crosstalk. For Downfall, a more recent one, Intel requested a 12 month embargo to release a microcode update.
      - tptacek 2y ago
        For all I know, that might be a reasonable ask for these kinds of vulnerabilities --- not that researchers have to honor them.

sofixa 2y ago

I wonder if Apple are being slow due to the complexity of the potential fix, or because they're dragging their feet.

kllrnohj 2y ago
Or it's a hardware issue and they don't have any way to do a microcode fix for this
- sebzim4500 2y ago
  It's could be unfixable without a significant performance penalty, but at minimum they could make safari do proper process isolation like every other browser does.
  - School-Cotton 2y ago
    I could easily imagine such a refactor of Safari taking more than 90 days even if Apple made it the highest possible priority.
    - goldsteinq 2y ago
      The bug is open since 2018, so clearly they don’t actually care about that. https://bugs.webkit.org/show_bug.cgi?id=184466 https://bugs.webkit.org/show_bug.cgi?id=184466
      - School-Cotton 2y ago
        Right, but that was before they knew about this exploit. My point was that even if they decided they needed to urgently switch to a multiprocesses architecture because it's the only way to mitigate this exploit, they might not be done yet.
        goldsteinq 2y ago
        This class of attacks is not new. Spectre demonstrated this possibility in 2018, and Apple was previously targeted by speculation attacks, e.g. https://gofetch.fail/ https://gofetch.fail/ or https://ileakage.com/ https://ileakage.com/.
alt227 2y ago
Because the fix will most likely kill performance, like Spectre/Meltdown did, and then their pretty graphs wont look so impressive any more.
latexr 2y ago
As someone who has reported several (software) security vulnerabilities to Apple, I couldn’t care less. Some of the things I reported are trivial to fix, and dealing with their team has been a frustrating experience. They don’t deserve extensions, they need to get their shit together and stop releasing new crap every year. Clearly they can’t do it properly.

tptacek 2y ago

The LVP vulnerability was reported in September, for what it's worth.

gabeio 2y ago
That's still more or less 120 days ago. Well over the 90 day typical window.
- tptacek 2y ago
  I'm not saying it's bad (I'm pretty close to a disclosure absolutist), though I don't really know what the norms are for hardware attacks --- both papers are well past the normal coordinated disclosure window for software.
  - hashstring 2y ago
    The vendor requested embargo timelines can get pretty crazy. Intel requested an embargo for 21 months for SRBDS/Crosstalk. For Downfall, a more recent one, Intel requested a 12 month embargo to release a microcode update.
    - tptacek 2y ago
      For all I know, that might be a reasonable ask for these kinds of vulnerabilities --- not that researchers have to honor them.