Google Native Client Puts x86 On the Web

[f0dder]

Via slashdot: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/ISJQZa42PCk/article.pl

t3rmin4t0r writes "Google has announced its Google native client, which enables x86 native code to be run securely inside a browser. With Java applets already dead and buried, this could mean the end of the new war between browsers and the various JavaScript engines (V8, Squirrelfish, Tracemonkey).

...am I the only one who thinks this is a very, very, VERY, VERY bad idea? At least java applets have limitations to what they can do, runs cross-platform, and has decent enough performance these days. I really hope this thing doesn't catch on... yeah sure, "it runs sandboxed", and nobody has ever broken out of a sandbox, right?

[40hz]

...am I the only one who thinks this is a very, very, VERY, VERY bad idea?

You speak the truth. I agree with you 100%.

Anything running "securely" inside a browser is ultimately only as secure as the browser itself.

And we all know how secure browsers are.

[mwb1100]

Sounds like "Son of ActiveX" - I'm skeptical of how well native code can be secured - it's just not easy to verify.

[f0dder]

You simply can't verify native x86 code - there's way too many tricky things that can be done. Somebody might come up with a partial solution that works "pretty OK for standard code", but malware authors aren't going to stick to "standard code". Trying to verify x86 code is a waste of time.

The only thing you can really do about native code is requiring the modules to be digitally signed, and then hope users have enough sense to not run code that's been signed by SneakySoftware Inc. And hope that signing authorities won't let anybody register "Mircosoft", "Goggle", etc.

Once the native code runs, you can try to sandbox it... but you'll ultimately fail. There's so many sneaky things x86 code can do, and so many holes you have to be aware of. AFAIK IE8 already has some sandboxing mode available... running in a thread with reduced privileges will get you a long way, but native code will be able to exploit browser bugs and the like, since native code can use pointers and (attempt to) write to arbitrary memory locations.

I really don't see wtf google is trying to achieve, they should stick with ActiveX (which fulfills native code needs) and JAVA (which is safer). The only way to get native code to run safely would be running it in a virtual machine... and virtual machines like vmware have had "escape outside the box" exploits. Even if you do a full emulation (without the run-certain-stuff-natively like vmware and friends do), you'd need some communication channels between the emulated code and the host, which might be open to exploitation. And the benefit of native code is speed, which would be killed by emulation.

Just focus on speeding up your javascript engine and memory allocators, dammit! (Oh, and beat SUN engineers with a big clue stick until they reach the JVM performance that Microsoft's JVM had).

[CWuestefeld]

One imagines that the x86 code that's running is effectively inside a VM, with the browser providing the OS. In this context, the fact that it's x86 is relatively meaningless, except that it promises ultra-high performance. But in every other respect, it's absolutely no different than javascript running in the browser. Granted, we've seen how that can be a risk. But this isn't creating a greater surface area for security holes, it's just rearranging that surface area.

[f0dder]

CWuestefeld: I disagree - they say sandbox, not VM... a VM would be massively overkill for a browser, and it's already been demonstrated that even VMs can be broken out of every now and then. And it's a lot different that Java or JavaScript, since those technologies don't have any facilities for directly accessing memory, performing syscalls, et cetera.

It's a bad idea, and we already have ActiveX anyway.

[Eóin]

Also I'd worry that the people responsible for extending native code and those who will be trying to secure this system are two different bodies.