Aetheric Research, Ltd.

A tool as powerful as the Native Client promises to be will have equally powerful misuses.  As discussed yesterday, NaCl is an extension of the functionality of Chrome, allowing it to act as something closer to a general hypervisor than ‘just’ a browser.  To understand the security implications of running generalized code in such a manner, it may be instructive to look at the Java VM.

The Java language was invented originally as a means of providing additional functionality to cellphones–before smartphones existed.  It spent much of the late ’90s being pushed as a ‘platform independent’ programming language–any platform that could run the Java Virtual Machine could run any Java program without issues.  This independence was at a much lower cost to speed than that of competitor interpreted languages; Java had a hybrid approach that rendered human-readable program instructions into an intermediate state between the human-readable instructions and the machine-readable code that compiled programs end up in–something called ‘bytecode’.

These bytecodes execute inside a sandbox environment set up by the JVM; much like the NaCl, the JVM seeks to isolate running code from touching parts of the machine other than what it is authorized to access–though unlike the JVM, the NaCl leverages the thread isolation offered by the Chrome environment to prevent inter-thread communications to (if I analyze this correctly) a greater extent than the JVM does.  

This sandboxing model is fairly safe as-is, though like all systems it is exploitable.  In the case of the JVM, exploits appear to focus on memory corruption, attempting to cause the virtual machine to execute instructions that will cause information to be written outside the authorized memory stack, and thence to execute instructions that have not been approved for execution by the trusted environment.

The exploit can be handled in various ways; one paper gives the possibility of loading a specially crafted program and waiting for a memory-corruption event to allow for the code execution to happen.  Existing vulnerabilities (that have been patched in the past) include corrupted image files and overflowing calendar modules.

The same vectors of attack are likely to happen inside NaCl, with similar effectiveness–that is, fairly ineffective unless some fault in the vetting of the code to be executed can be found.  With open-sourced projects, such faults are unlikely to persist, given the number of eyes (especially those with a vested interest in ensuring the project’s success) examining the code, as well as the well-publicized monetary rewards posted as bounties for bug reporting by Google.  Still, it would be a mistake to assume safety–as always, the basic rules will still apply, and a new vulnerability in the process could be found at any time.  

The ChromeOS (and by extension the chromium browser) is to include the NaCl–the Native Client.  Condiment puns abound, given that NaCl is also the chemical formula for table salt.  NaCl is an implementation of a means to run machine code inside the framework of the browser, granting webapps a significant performance boost.

The Chrome paradigm is one of multithreaded sandboxing: each thread (more or less synonymous with “browser tab”) has its own area of memory and its own slice of processor time to work with.  In this model, the browser tabs are like very limited virtual machines, and the parent browser process much like a hypervisor–individual meltdowns of machines are (at least in theory) irrelevant to the operation of the other threads, and can be cleaned up and removed by the parent process should it become necessary.

NaCl takes this a little bit closer to a real VM setup, in that it offers a way to run code on the ‘bare metal’–that is, using the native hardware of the user’s machine, rather than working via a javascript implementation like current HTML5 apps.  

The sandboxing requirement is still maintained, in that the Native Client only (theoretically) allows code to run that will respect the limits of the sandboxing system–this is important, given that running code directly allows for a great deal more leeway and leveraging of resources than execution inside a javascript interpreter.  The NaCl executables are, for all intents and purposes, the same kind of machine code that you would run directly on your computer, and have all the associated advantages (speed, especially) and disadvantages (ability to cause harm) that this entails.

One intended use for the NaCl framework is for cloud apps to export a portion of the processing load to the client systems, to enable a better user experience.  Games, especially, will benefit from the Native Client, given that the graphical rendering calculations are rather more intensive than those required for standard web apps.  Statistical and rendering applications may also see a benefit from the increased performance available under this model.

Another is for webapps to extend parts of their functionality to the client machine in order to limit the amount of data required to be sent and received–an important consideration for people who may be on slow or capped internet connections.  In this model, the NaCl app could be downloaded once, and thereafter traffic to and from the hosting server would be limited to user provided or requested data–all the processing and rendering of the information could happen locally.

One usage that has not appeared in the official documentation, at least as far as I’ve seen, but seems as though it would be appropriate would be an implementation of the BOINC client–being able to run folding@home, seti@home or any of the other distributed computing projects inside a browser tab could result in significantly increased uptake.  Given that the format of the NaCl executables is fairly close to that of an existing BOINC implementation, a comparatively limited amount of development would be required to adapt it to this platform.

NaCl offers significant opportunities to developers; much can be done with native machine code that cannot be effectively done with javascript or other interpreted languages.  It also offers significant dangers–of which the developers appear very much aware.  On the whole, though, NaCl appears likely to be able to provide a much improved user experience, with the potential for significant improvements for developers–with NaCl, much like Java before it, they’ll be able to write one program and run it on any platform, rather than having to target a specific OS.  Unlike Java, which handled sandboxing by implementing a sort of virtual machine and compiling code into a special format to run on top of it, NaCl allows the execution to be handled directly by the processor–this should allow NaCl applications to run much faster than the equivalent Java apps.  

Native Client is still very much experimental, but can be enabled for users of the Chromium browser by going to the about:flags page, clicking the ‘Enable’ button under the Native Client option, and restarting your browser.  You can test out some of the functionality with the examples found in the Gallery page.