4 ms·

If you're just interested in the PoC, it's available here: https://leaky.page/ https://leaky.page/ and looks like the code is at https://github.com/google/secur

If you're just interested in the PoC, it's available here: https://leaky.page/ https://leaky.page/ and looks like the code is at https://github.com/google/security-research-pocs/tree/master/spectre.js https://github.com/google/security-research-pocs/tree/master...

pantalaimon 6y ago
I have `mitigations=off` and the PoC didn't work for me on Chrome / i7-3770.
- modeless 6y ago
  Worked on my i7-7920HQ.
MauranKilom 6y ago
Tried it in Firefox, but the timing result in the first step was already quite noisy (the two peaks overlapped to about 60%), and the second step didn't complete after 3 minutes of dismissing repeated "a website is slowing the page down" prompts. That doesn't mean Firefox is safe, to be clear. Just that this PoC doesn't work well for my combination of browser and CPU.
- throwanem 6y ago
  It may not work in Firefox due to the restricted resolution of performance.now() there; per the demo page, that is 5μs in desktop Chrome - Firefox meanwhile rounds to the nearest millisecond, per https://developer.mozilla.org/en-US/docs/Web/API/Performance/now https://developer.mozilla.org/en-US/docs/Web/API/Performance.... That said, the demo also mentions a paper [1] on high-resolution timing channels available in Javascript without needing to rely on the performance API. I don't know how well a Spectre attack relying on such a timing method would fare in any browser. Looking at that paper's abstract and code samples, I think most if not all of the timing channels it describes rely entirely on tight loops, so one or more of them being attempted would explain the high CPU usage you noticed. [1] https://pure.tugraz.at/ws/portalfiles/portal/17611474/fantastictimers.pdf https://pure.tugraz.at/ws/portalfiles/portal/17611474/fantas...
  - lights0123 6y ago
    Now of course if they enabled COOP/COEP like their own guide recommends[1], that woukd be different. [1]: https://web.dev/coop-coep/ https://web.dev/coop-coep/
uyt 6y ago
The memory dump demo seemed to work for my computer. Does that mean I am missing some spectre mitigation stuff? I thought this was already fixed a few years ago? How do I stop this demo from working? (linux, intel i7, chrome 89)
- ddworken 6y ago
  Last year Chrome published a great paper on this[1]. The summary is that we no longer think it is possible to completely prevent speculative execution bugs. A big focus nowadays is on providing tools (mainly via HTTP headers) that allow a website to opt-in to a more strict security model where specific sensitive resources can't end up in a process that is running untrusted code. If you're curious, check out this[2] document which explains a bunch of these different mechanisms. Disclosure: I work at Google and am involved in deploying some of these features internally. [1]: https://arxiv.org/pdf/1902.05178.pdf https://arxiv.org/pdf/1902.05178.pdf [2]: https://w3c.github.io/webappsec-post-spectre-webdev/ https://w3c.github.io/webappsec-post-spectre-webdev/
  - uyt 6y ago
    > Chromium’s threat model, for instance, now asserts that "active web content … will be able to read any and all data in the address space of the process that hosts it" This was a huge WTF to me. I have been doing web dev for 10+ years and can barely get origin based security right. Now we're expected to understand process level security boundaries too??? That said, are there any resources explaining how the chromium process works? It has always been a black box to me. For example if a form is being autofilled, don't those personal info/passwords have to be loaded into memory? There's an infinite amount of things that I thought was inaccessible solely because there's no JS api to access the data that I now need to think about. Direct memory access is just a huge can of worms, no?
    - ddworken 6y ago
      Yeah, I think it is a bit unfortunate that there doesn't seem to be any way of hiding this implementation detail from developers. In general though, Chrome is very thoughtfully designed so things mostly work as you'd hope. The core of the process model is that each site (e.g. `ycombinator.com` not `news.ycombinator.com`) gets its own process. This [0] has a great list of things they've considered when designing site-isolation. For example, Chrome's password manager does respect site isolation and is designed to operate across multiple processes[1]. [0]: https://chromium.googlesource.com/chromium/src/+/master/docs/security/compromised-renderers.md https://chromium.googlesource.com/chromium/src/+/master/docs... [1]: https://chromium.googlesource.com/chromium/src/+/master/components/password_manager/README.md https://chromium.googlesource.com/chromium/src/+/master/comp...

pantalaimon 6y ago

I have `mitigations=off` and the PoC didn't work for me on Chrome / i7-3770.

modeless 6y ago
Worked on my i7-7920HQ.

MauranKilom 6y ago

Tried it in Firefox, but the timing result in the first step was already quite noisy (the two peaks overlapped to about 60%), and the second step didn't complete after 3 minutes of dismissing repeated "a website is slowing the page down" prompts. That doesn't mean Firefox is safe, to be clear. Just that this PoC doesn't work well for my combination of browser and CPU.

throwanem 6y ago
It may not work in Firefox due to the restricted resolution of performance.now() there; per the demo page, that is 5μs in desktop Chrome - Firefox meanwhile rounds to the nearest millisecond, per https://developer.mozilla.org/en-US/docs/Web/API/Performance/now https://developer.mozilla.org/en-US/docs/Web/API/Performance.... That said, the demo also mentions a paper [1] on high-resolution timing channels available in Javascript without needing to rely on the performance API. I don't know how well a Spectre attack relying on such a timing method would fare in any browser. Looking at that paper's abstract and code samples, I think most if not all of the timing channels it describes rely entirely on tight loops, so one or more of them being attempted would explain the high CPU usage you noticed. [1] https://pure.tugraz.at/ws/portalfiles/portal/17611474/fantastictimers.pdf https://pure.tugraz.at/ws/portalfiles/portal/17611474/fantas...
- lights0123 6y ago
  Now of course if they enabled COOP/COEP like their own guide recommends[1], that woukd be different. [1]: https://web.dev/coop-coep/ https://web.dev/coop-coep/

uyt 6y ago

The memory dump demo seemed to work for my computer. Does that mean I am missing some spectre mitigation stuff? I thought this was already fixed a few years ago? How do I stop this demo from working? (linux, intel i7, chrome 89)

ddworken 6y ago
Last year Chrome published a great paper on this[1]. The summary is that we no longer think it is possible to completely prevent speculative execution bugs. A big focus nowadays is on providing tools (mainly via HTTP headers) that allow a website to opt-in to a more strict security model where specific sensitive resources can't end up in a process that is running untrusted code. If you're curious, check out this[2] document which explains a bunch of these different mechanisms. Disclosure: I work at Google and am involved in deploying some of these features internally. [1]: https://arxiv.org/pdf/1902.05178.pdf https://arxiv.org/pdf/1902.05178.pdf [2]: https://w3c.github.io/webappsec-post-spectre-webdev/ https://w3c.github.io/webappsec-post-spectre-webdev/
- uyt 6y ago
  > Chromium’s threat model, for instance, now asserts that "active web content … will be able to read any and all data in the address space of the process that hosts it" This was a huge WTF to me. I have been doing web dev for 10+ years and can barely get origin based security right. Now we're expected to understand process level security boundaries too??? That said, are there any resources explaining how the chromium process works? It has always been a black box to me. For example if a form is being autofilled, don't those personal info/passwords have to be loaded into memory? There's an infinite amount of things that I thought was inaccessible solely because there's no JS api to access the data that I now need to think about. Direct memory access is just a huge can of worms, no?
  - ddworken 6y ago
    Yeah, I think it is a bit unfortunate that there doesn't seem to be any way of hiding this implementation detail from developers. In general though, Chrome is very thoughtfully designed so things mostly work as you'd hope. The core of the process model is that each site (e.g. `ycombinator.com` not `news.ycombinator.com`) gets its own process. This [0] has a great list of things they've considered when designing site-isolation. For example, Chrome's password manager does respect site isolation and is designed to operate across multiple processes[1]. [0]: https://chromium.googlesource.com/chromium/src/+/master/docs/security/compromised-renderers.md https://chromium.googlesource.com/chromium/src/+/master/docs... [1]: https://chromium.googlesource.com/chromium/src/+/master/components/password_manager/README.md https://chromium.googlesource.com/chromium/src/+/master/comp...