An independent security researcher has discovered ways to bypass Google's Native Client (NaCl) implementation,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
exploiting Google Chrome sandbox security weaknesses to execute code on a system.
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.
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.
More from Black Hat 2012
See more of SearchSecurity.com's special coverage of Black Hat 2012.
"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."
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.