Black Hat 2012: Google Chrome sandbox security flaws to be exposed

An independent security researcher has discovered ways to bypass Google's Native Client (NaCl) implementation, exploiting Google Chrome sandbox security weaknesses to execute code on a system.

NaCl allows you to run different plug-ins that are written in native code like C++, but run them with the same safety that users have come to expect from JavaScript.

Chris Rohlf,
president, Leaf SR

Chris Rohlf, founder and president of New York-based Leaf Security Research, said he has found numerous vulnerabilities in the Google NaCl implementation, and will present his findings at the 2012 Black Hat Briefings in Las Vegas.

Google's Native Client was built so developers could use alternatives to Adobe Systems Inc.'s Flash, Microsoft's Silverlight and other third-party browser plug-ins that are often targeted by attackers. It was created to surround plug-ins with two layers of protection. Using an inner sandbox, it validates plug-ins and isolates any coding errors while preventing an attacker from entering the browser processes. It interacts with Google Chrome's outer sandbox, designed to prevent code from being executed on the user's system. NaCl, introduced in 2008, began as a research project, and was later implemented in Chrome 14.

"NaCl allows you to run different plug-ins that are written in native code like C++," Rohlf said, "but run them with the same safety that users have come to expect from JavaScript."

Rohlf said the flaws he plans to disclose have been patched by Google, but it's likely there are additional weaknesses that could be used by an attacker to bypass the inner sandboxing feature altogether.

"Instead of defeating the inner sandbox," Rohlf said, "you can take the easy way and go after the Chrome renderer itself," which is the Chrome component that takes downloaded webpage codes and displays the code as a webpage. "Find vulnerabilities in the Chrome renderer and then go after them with an untrusted NaCl module." 

Despite the implementation weaknesses, the researcher said the Native Client is a good step by Google to provide additional security to Chrome users by giving software developers the ability to create highly functional plug-ins, such as PDF viewers or multimedia players, with additional protections.

Rohlf was a speaker at Black Hat in 2009 and 2011. He was principal security consultant at New York City-based Matasano Security. In his 2011 Black Hat Briefings session, "Attacking client-side JavaScript Just In Time (JIT) compilers," (.pdf) Rohlf and Yan Ivnitskiy, both then-consultants at research and consulting firm Matasano Security, focused on JIT compilers in Firefox and in the LLVM project, an open source compiler.

The research publicized a number of weaknesses, Rohlf said. Shortly thereafter, the Mozilla Firefox Project hardened its JIT engine. JavaScript JIT compilers are in their infancy and developers are constantly changing them, Rohlf said.

"They have only hit browsers over the past two or three years and they are going to keep changing for the foreseeable future," Rohlf said. "We're going to see a lot of vulnerabilities being implemented and a lot of problems reinvented from new JIT engines."

Java weaknesses

Rohlf has been researching browser component vulnerabilities for more than a decade. He said he isn't a big fan of Java, a ubiquitous Web application programming language that has become a favorite target of cybercriminals. Complexity also causes weaknesses in Java that are targeted by cybercriminals. Rohlf said Java components, such as the Just In Time engine compiler and byte code interpreter -- used to store and interpret code instructions -- are riddled with vulnerabilities.

"A large amount of the Java codebase was written long before a lot of things we know about application security today," Rohlf said. "It runs almost unrestricted in your browser."

Rohlf advocates disabling Java, using it only when it is explicitly needed.