Hacker News new | ask | show | jobs
by willvarfar 4006 days ago
The buffer overflow in NaCL extension that comes with Chrome e.g. Flash may be just the a stepping stone in a Pwnium entry that escapes the sandbox through yet another webGL validation bug or something.

Why would Google want to not bother applying a belt-and-braces exploit mitigation that costs 0% CPU?
1 comments
tptacek 4005 days ago
You're not following my point. NaCL programs are content-controlled. Attackers start out with arbitrary code execution.
link
willvarfar 4005 days ago
One NaCL use case is a plugin downloaded by the page

But NaCL is also used to isolate "built in" embeddables e.g. Flash, which I have used as an example of a NaCL plugin that comes with chrome in both the previous posts?

Another example is the voice activation plugin that got them into so much trouble recently...

Imagine you walk past your colleagues computers saying things like "let's google something naughty" loudly...

And now let's extend that to playing an audio snippet that invokes a stack smash? :)

link
tptacek 4005 days ago
I'm still not following how hardening Nacl against memory corruption bugs can help Chrome, given that Nacl-enabled Chrome already runs content-controlled Nacl code.
link
willvarfar 4005 days ago
Are the pdf viewer or flash players 'content-controlled'?

Are not google-bundled plugins allowed to run even when the user doesn't allow third-party NaCL plugins to run?

Its belt and braces. Why wouldn't chrome bother to enable a pass that costs 0% runtime performance? After all the money and time Google have sunk into other runtime checks like ASan, why wouldn't they also enable this?

It made me think: what other 'exploit mitigations' do Google put into NaCL, even though its sandboxed? So I quickly gooogled to see if they use ASLR inside NaCL, for example. Here's what I found:

https://code.google.com/p/nativeclient/issues/detail?id=2962

So they added ASLR, and they made a nice point:

"for the threat model where a NaCl module might process untrusted input, it would be nice to provide ASLR for the NaCl module so untrusted input won't (easily) be able to take control of the NaCl module (if/when the NaCl module has bugs). (this is a different threat model that the usual one in NaCl, where the NaCl module is untrusted. here we are trying to make sure that a NaCl module, which is executing code on the behalf of some domain/web site, isn't easily pwned, even if the NaCl runtime is itself okay.)"

link