Tue 8 Mar, 2011
Tags: chrome, NaCl, native client, security, virtual machines, web security
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.