undefined | Better HN

0 pointswillvarfar10y ago0 comments

Well bother business-wise? I mostly included them for completeness. I'm a bit fan of PNaCL but its not really taken off.

So technically bother, then? NaCL programs are just as susceptible to buffer-overflow as conventional programs, its just they are better sandboxed. Exploit mitigation is a belt-and-braces thing, and I can't see why Google wouldn't be enabling this pass right now as we speak.

You have something compiled in NaCL like the Flash plugin and it can control the camera and stuff and you are hoping that an attacker can't feed it some malformed JPEG or something that makes it use the caps it has in a bad way etc.

Here's the only thread I could dig up on buffer overflows in NaCL: http://permalink.gmane.org/gmane.comp.security.nativeclient....

0 comments

tptacek10y ago

It's not that they're better sandboxed; it's that regardless of whether memory corruption exploits work, in the NaCL security model, if the sandbox doesn't work, you're fucked regardless. So why bother with hardened runtimes?

haberman10y ago

Your threat model seems to be that anyone who sends input to a sandboxed app should be assumed to have full control of it. But the apps frequently process input without wanting to give the sender of that input access to all its resources.

By your analysis, Gmail could implement a feature that lets a sender run arbitrary JavaScript in the recipient's browser, and this would have no security impact as long as the JavaScript sandbox was not escaped. But in reality this would be a huge breach, because there are valuable things inside the sandbox that attackers should not have access to.

Put another way, this wouldn't help defend Chrome from NaCl, but it would help defend the NaCl app from it's clients. This would be in Google's interest to implement because it would make the platform more attractive to developers.

tptacek10y ago

That seems like an uncommon scenario for the kinds of things NACL gets used for. These are intrinsically server-controlled applications, when they're applications at all (my real sense of what NACL is about is "another tool to migrate away from things like Flash and plugins; ie: a platform for video codecs).

I see your point. I guess you're saying, there could be a photo editing app in which Alice can send pictures to Bob, and Mallory might send a malicious picture to Alice that coerces her client into betraying all its photos.

willvarfarOP10y 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?

tptacek10y ago

You're not following my point. NaCL programs are content-controlled. Attackers start out with arbitrary code execution.

1 more reply

j / k navigate · click thread line to collapse

0 pointswillvarfar10y ago0 comments

Well bother business-wise? I mostly included them for completeness. I'm a bit fan of PNaCL but its not really taken off.

Here's the only thread I could dig up on buffer overflows in NaCL: http://permalink.gmane.org/gmane.comp.security.nativeclient....

0 comments

tptacek10y ago

haberman10y ago

tptacek10y ago

willvarfarOP10y ago

Why would Google want to not bother applying a belt-and-braces exploit mitigation that costs 0% CPU?

tptacek10y ago

You're not following my point. NaCL programs are content-controlled. Attackers start out with arbitrary code execution.

1 more reply

j / k navigate · click thread line to collapse