[HN Gopher] Spectre in JavaScript
___________________________________________________________________
Spectre in JavaScript
Author : jeffbee
Score : 127 points
Date : 2021-03-12 17:11 UTC (5 hours ago)
(HTM) web link (leaky.page)
(TXT) w3m dump (leaky.page)
| toomim wrote:
| So given that the only mitigation to Spectre is to isolate each
| website into its own underlying OS process, it seems very
| important to know which browsers are doing that.
|
| Chrome is doing it. What about Firefox and Safari? What about
| Edge? Do they implement site isolation?
| JackMcMack wrote:
| Firefox reduced the timer precision, this demo does not work.
| https://developer.mozilla.org/en-US/docs/Web/API/Performance...
|
| On Chrome I have "too many false negatives" on 1st gen Ryzen.
| ddworken wrote:
| Chromium has site-isolation (with some caveats around phones
| with limited resources) so both Chrome and Edge have site-
| isolation. Firefox is getting very close with Project Fission
| [1] and I predict they'll ship it relatively soon. Currently
| Safari doesn't have site-isolation and AFAIK they have not
| publicly committed to anything in terms of getting there. They
| have done some work in this space (search around for Process
| Swap on Navigation (PSON)) but it isn't complete.
|
| [1]: https://wiki.mozilla.org/Project_Fission
| Paul-ish wrote:
| The proof of concept is in Chrome, so it appears Chrome's
| mitigations are not sufficient.
| toomim wrote:
| No, the POC only shows the script leaking memory into
| javascript running within the same process, and thus the same
| site. Chrome is still preventing the info from leaking across
| sites.
| ddworken wrote:
| The big caveat to this is that an attacker can generally
| get a browser to include a cross-site resource in their
| process. For example, `<img
| src="https://sensitive.com/myprofilepic.png">` will cause
| the image to be loaded in the attacker's process where they
| can then potentially steal it. The article "Post-Spectre
| Web Development" goes into details on how sites can defend
| against this (and other vectors).
| jeffbee wrote:
| That's why there was the recent W3C draft about Spectre and
| the policies around which sites can frame other sites.
| eloff wrote:
| No, the attack always works, whether there's an isolated
| process or not. In Chrome's design you shouldn't be able to
| access any data of value with the attack, that is data from
| other sites (like cookies) or privileged data. I don't know
| if that's indeed true or not in Chrome, but that's why it was
| designed that way.
| ddworken wrote:
| Chrome's design ensures that Spectre can only access
| resources that end up in an attacker controlled process.
| And this [1] post on "Post-Spectre Web Development" goes
| into detail about how a given website can ensure that its
| resources don't end up in an attacker controlled process.
| There are also a number of default protections against this
| like SameSite cookies and CORB that protect some resources
| by default.
|
| [1]: https://w3c.github.io/webappsec-post-spectre-webdev/
| andrewla wrote:
| I may be wrong about this, and about specifically how exposed
| browsers are to Spectre, but the only real mitigation here,
| since protected memory can be accessed through the same
| mechanism, is disabling branch prediction and CPU caches, or
| barring those caches being reused across threads or execution
| contexts.
|
| Or completely redesigning those aspects of CPU behavior to
| remove the ability for similar timing attacks.
| swiley wrote:
| Or just not accepting and evaling arbitrary code from every
| single website the user visits, including ones that should
| only be static documents or forms.
|
| That this is generally considered ok boggles the mind. That
| browser vendors have made it difficult for users to disable
| this is insane! Even MS Internet Explorer gave users at least
| _that_ security tool!
| emilsedgh wrote:
| the modern web doesn't work without Javascript. It's as
| simple as that.
|
| People like you who want to turn js off are a very small
| niche. And you have better solutions. Run your browser in a
| remote server using rdp or vnc. I think it may be equally
| safe and you may actually have a larger chunk of web
| working for you.
| paulryanrogers wrote:
| Considering the increasing sandboxing and protections I
| think we're getting closer to browsers in VMs already.
| Someday I can see a permission prompt to allow
| performance sensitive sites lower level access.
| astrobe_ wrote:
| The "modern web" does not _want_ to work without JS. It
| definitely _could_ work without JS for the most part.
| paulryanrogers wrote:
| Chrome desktop does actually allow you to run with JS
| disabled and allow per site with only a few clicks.
| the8472 wrote:
| Attempting to take those cache timings in FF doesn't result in
| anything like the demo.
|
| https://a.pomf.cat/gawfxu.png
| tillinghast wrote:
| Friday afternoon, I was really kind of looking forward to
| https://en.wikipedia.org/wiki/Spectre_(1991_video_game)
| sircastor wrote:
| This was my first thought too. :/
| sircastor wrote:
| Well, this steps up the game quite a lot. I'd considered the CPU
| attacks relatively unconcerning because it required executing
| code locally. Bring able execute from a web page makes for a
| broader attack vector.
| swiley wrote:
| This is not new and it's half the reason I browse the web in
| icecat/elinks. The other half being that most of the javascript
| out there is written without regard for resource consumption.
| paulryanrogers wrote:
| What protections are unique to IceCat?
| saagarjha wrote:
| Presumably the different kind of "security by obscurity"
| that comes with using software that nobody else uses and
| thus nobody will spend resources targeting
| forgotmypw17 wrote:
| i,ve also found that accessibility and content quality are
| strongly correlated, saving me reading time.
| gbrown_ wrote:
| JavaScript based examples are shown in the Spectre paper.
| anyfoo wrote:
| You have to specify a whole lot more context if you talk about
| executing code "locally" vs. executing "from a web page".
|
| JavaScript usually gets JIT'ed into machine language code. That
| code gets executed locally. There are usually a bunch of
| differences in terms of form and restrictions around that code,
| but this might well be a case where most of those differences
| don't matter.
|
| Or in other words, browsers are just compilers/interpreters
| like any other, albeit very hardened ones because of the large
| exposure of untrustworthy code they are subject to. But if an
| attack fundamentally skirts around sandboxes, the browser
| sandbox won't help.
|
| It's Turing machines all the way down.
| swiley wrote:
| this doesn't work on my pinephone although my hands are pretty
| sweaty now.
| AzzieElbab wrote:
| Now I am become Death.js, the destroyer of worlds
| JoachimSchipper wrote:
| This is effectively a demo for
| https://news.ycombinator.com/item?id=26436515.
| feross wrote:
| It's _actually_ a demo for it. It 's linked from the post.
| toomim wrote:
| This doesn't run in Safari on an M1. I'm getting is error in the
| JS console: [Error] RuntimeError: Out of bounds
| memory access (evaluating 'this.wasm.exports.oscillateTreePLRU2')
| <?>.wasm-function[2] (memory_frame.html:78) wasm-stub
| oscillateTreePLRU2 _timeL1 (memory_frame.html:78)
| leakMeTestSet (memory_frame.html:146) Global Code
| (memory_frame.html:165)
| bullen wrote:
| To me this changes nothing to the 30% CPU wasted by default with
| new linux distributions.
|
| Linus said he wanted the workarounds disabled by default, why
| didn't anyone listen?
|
| I'm not browsing javascript sites on my linux server!?
|
| If the server is compromised they don't need to use
| meltdown/spectre to do damage since servers need root for
| everything useful (open port <1024)?!
| mhh__ wrote:
| And what happens if they work out enough about your server to
| use ROP?
| bullen wrote:
| Would Java be vulnerable to ROP?
| Spivak wrote:
| ROP is a strategy to leverage an existing vulnerability to
| do more so it's not really language specific. It's a
| question of whether you can find a vuln in your JVM or any
| native code it or your app calls out to.
| bullen wrote:
| Well if they find a vulnerability in the most used peice
| of code in existence (JVM) then I'm pretty sure it will
| get patched no?
| pjmlp wrote:
| Depends, if it is on its Android equivalent, ART, it
| won't matter.
| anyfoo wrote:
| The idea that root has absolute privileges, or even that it is,
| like in the olden Linux days, kernel-equivalent (through
| /dev/kmem, ioperm etc.), is outdated.
|
| Nowadays, the focus going forward is much more on giving every
| piece the privileges it needs, and not have an "absolute
| privilege" entity. (Outside of the kernel, although even for
| that it's less and less true anymore.)
| anyfoo wrote:
| As for not planning to run untrusted code in any of those
| pieces: It's bad if compromise through bugs of any component,
| however tiny, potentially leads to the ability to siphon off
| secrets from your server globally.
| minitech wrote:
| > If the server is compromised they don't need to use
| meltdown/spectre to do damage since servers need root for
| everything useful (open port <1024)?!
|
| - there are lots of useful things you can do without root
|
| - you don't need root to bind to port numbers below 1024 on
| Linux, just CAP_NET_BIND_SERVICE
|
| - when you do need root, you can usually drop it either
| partially or completely
| bullen wrote:
| Ok, thx!
|
| Can you combine that with nohup?
|
| nohup setcap 'cap_net_bind_service=+ep' blabla...
| lrvick wrote:
| No, but someone that finds even an unprivileged path to execute
| code on your server can fully control root on it if spectre is
| carried out successfully.
| [deleted]
| paulryanrogers wrote:
| Distros probably want to fail safe. That said most desktop
| installs are probably single user, so should be safe to do
| there
| bstar77 wrote:
| I didn't experience the issue on my Threadripper2 with Windows
| 10. Is that because of OS patches or because my CPU is not
| affected?
___________________________________________________________________
(page generated 2021-03-12 23:00 UTC)