[HN Gopher] A Spectre proof-of-concept for a Spectre-proof web
___________________________________________________________________
A Spectre proof-of-concept for a Spectre-proof web
Author : theafh
Score : 88 points
Date : 2021-03-12 15:03 UTC (7 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| EE84M3i wrote:
| If you're just interested in the PoC, it's available here:
| https://leaky.page/ and looks like the code is at
| https://github.com/google/security-research-pocs/tree/master...
| uyt wrote:
| 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 wrote:
| 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 [2]:
| https://w3c.github.io/webappsec-post-spectre-webdev/
| uyt wrote:
| > 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 wrote:
| 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/+/mas
| ter/docs... [1]: https://chromium.googlesource.com/chromi
| um/src/+/master/comp...
| pantalaimon wrote:
| I have `mitigations=off` and the PoC didn't work for me on
| Chrome / i7-3770.
| modeless wrote:
| Worked on my i7-7920HQ.
| MauranKilom wrote:
| 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 wrote:
| It may not work in Firefox due to the restricted resolution
| of performance.now() there; per the demo page, that is 5ms in
| desktop Chrome - Firefox meanwhile rounds to the nearest
| millisecond, per 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/fan
| tas...
| lights0123 wrote:
| Now of course if they enabled COOP/COEP like their own
| guide recommends[1], that woukd be different.
|
| [1]: https://web.dev/coop-coep/
| [deleted]
| Mkm1800 wrote:
| Hy wwl
| modeless wrote:
| > in our tests the attack was successful on several other
| processors, including the Apple M1 ARM CPU, without any major
| changes.
|
| Interesting!
| mhh__ wrote:
| Not interesting to my eyes. If M1 was vulnerable to Meltdown
| then Apple need a smacked bottom, but Spectre is a lesser but
| much harder evil to get rid of - there isn't an obvious
| solution to avoiding these side channels on a processor with
| multiple cores sharing a memory bus
| stefan_ wrote:
| Really? Their proposed mitigations are various Cross Origin
| Resource restrictions?
|
| That's the equivalent of saying "just don't run bad JS code".
| It's not workable. Have they given up?
| ddworken wrote:
| See this[1] paper for more information. I think from the
| browser POV it is more about admitting that it just isn't
| possible to reliably mitigate Spectre and instead focusing on
| what can be done at the browser level. And at the browser
| level, it is possible to ensure that sensitive resources don't
| end up in processes running attacker JS.
|
| Of course this could be fixed at the CPU level, but
| realistically very few people want that since that would
| drastically slow down modern CPUs which rely on speculative
| execution.
|
| [1]: https://arxiv.org/pdf/1902.05178.pdf
|
| Disclosure: I work at Google and am involved in deploying some
| of these cross-origin resource restrictions internally.
| the8472 wrote:
| But it's still going to help exploits against the browser,
| isn't it? Letting code poke around until it finds addresses
| it needs or something like that.
| ddworken wrote:
| As I understand it (though I don't work directly on
| Chrome), a key part of Chrome's threat model is that a
| compromised renderer process (where there is one renderer
| process per site) has limited security impact. So being
| safe against Spectre (which gives a read primitive in the
| renderer process) is just a subset of being safe against a
| compromised renderer process.
| Shared404 wrote:
| > "just don't run bad JS code". It's not workable.
|
| A little NoScript goes a long way. At least that way you can
| pick what you want to run.
| stefan_ wrote:
| Oh yes, if you ask me, throw this JIT shit out. Whats the
| spectre rate like if you need to do it through slow as
| molasses bytecode? 1b/minute?
| monocasa wrote:
| It's not the JIT that's the issue, but a deeper problem.
| It's untrusted instruction streams which.you can get from
| just untrusted data too.
|
| Netspectre was able to dump kernel memory just from
| untrusted received network packets, no jit required.
___________________________________________________________________
(page generated 2021-03-12 23:01 UTC)