Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Spectre proof-of-concept for a Spectre-proof web

security.googleblog.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: A Spectre proof-of-concept for a Spectre-proof web

#21

Post by ddworken »

the8472 wrote: post #16
ddworken wrote: post #13

Earlier quoted context omitted.

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…

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.

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.

Re: A Spectre proof-of-concept for a Spectre-proof web

#22

Post by monocasa »

stefan_ wrote: post #18
Shared404 wrote: post #17

Earlier quoted context omitted.

> "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.

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?

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.

Re: A Spectre proof-of-concept for a Spectre-proof web

#24

Post by smt1 »

I remember working on some correlation-based speculative branch prediction algorithms in college (mid 2000s), and accidentally coming across similar "bugs" with chips back then.

Of course, this was during the race to claim as much gigahertz so it wasn't security (at this level, anyways) that people were interested in at all.

Re: A Spectre proof-of-concept for a Spectre-proof web

#25

Post by ddworken »

medlyyy wrote: post #23

I will admit I don't fully understand the implications of this. Doesn't this mean it's essentially game over for running untrusted JS by-default? Doesn't default-deny functionality like NoScript have to become mandatory in browsers for security? If not, why not?

This only allows reading data from the current process. Chrome and Edge have something called site-isolation where every site has its own process. In principle, this means that a site can only read its own resources. The catch here is that there are a bunch of different ways a site can include potentially sensitive resources from other sites (e.g. via referencing them with an `img` tag). So sensitive endpoints need to opt-in to additional protections that ensure they do not end up in cross-site browser processes.

But no, this isn't game over for running untrusted JS. It just means that we need to assume that JS can access anything in the same process.

Re: A Spectre proof-of-concept for a Spectre-proof web

#26

Post by fortran77 »

> however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.

Wow! How come Apple, on this brand new processor, wasn’t able to mitigate against Spectre? (A quick google shows that many Apple fan sites hailed the M1 as being immune to what they called “intel bugs’)

Re: A Spectre proof-of-concept for a Spectre-proof web

#27

Post by xiphias2 »

Shared404 wrote: post #17
stefan_ wrote: post #10

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?

> "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.

It seems to me like timers and multi-threading make these things possible, so why couldn't the web site ask for access for those resources from the user? Most web sites don't need these.

HN should work without reading timers at all for example.

Re: A Spectre proof-of-concept for a Spectre-proof web

#28

Post by SAI_Peregrinus »

fortran77 wrote: post #26

> however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes. Wow! How come Apple, on this brand new processor, wasn’t able to mitigate against Spectre? (A quick google shows that many Apple fan sites hailed the M1 as being immune to what they called “intel bugs’)

Spectre is a consequence of just about any speculative execution combined with shared CPU caches (or even shared memory busses, even without shared cache). Since nobody (including Apple) knows how to make a CPU fast without those things all high-performance CPUs are potentially vulnerable. Unless we go back to single-core single-processor systems without speculative execution (or flushing all cache on every context switch) some variant or other of a Spectre attack will be possible.

If you want to be invulnerable to this you're basically stuck with a microcontroller.

Re: A Spectre proof-of-concept for a Spectre-proof web

#29

Post by toomim »

medlyyy wrote: post #23

I will admit I don't fully understand the implications of this. Doesn't this mean it's essentially game over for running untrusted JS by-default? Doesn't default-deny functionality like NoScript have to become mandatory in browsers for security? If not, why not?

It means game over for users who run browsers like Safari, which don't isolate each site to their own OS process.

If you load Javascript from one site, that JS can read the entire state of memory for another site, if it is within the same OS process. This means that any site can include some nefarious javascript that reads all the cookies and passwords for the user on other sites, and then log in as them.

Re: A Spectre proof-of-concept for a Spectre-proof web

#30

Post by medlyyy »

toomim wrote: post #29
medlyyy wrote: post #23

I will admit I don't fully understand the implications of this. Doesn't this mean it's essentially game over for running untrusted JS by-default? Doesn't default-deny functionality like NoScript have to become mandatory in browsers for security? If not, why not?

It means game over for users who run browsers like Safari, which don't isolate each site to their own OS process. If you load Javascript from one site, that JS can read the entire state of memory for another site, if it is within the same OS process. This means that any site can include some nefarious javascript that reads all the cookies and passwords for the user on other sites, and then log in as them.

Seems like Firefox doesn't have this feature yet either?

https://wiki.mozilla.org/Project_Fission

Post reply on HN