Details have been disclosed about vulnerabilities exploited in Chrome and Java during the Pwn2Own contest. Google made patches available for the Chrome flaw within 24 hours, while Oracle patched Java fully last week.
September 1, 2016 , 11:52 am
July 21, 2016 , 5:04 pm
June 2, 2016 , 12:59 pm
Details were not disclosed by the researchers, who netted tens of thousands for their exploits, until last Friday, more than a month after the contest.
The exploits in question here used a variety of techniques to break both the popular browser and the browser plug-in. Java has had a particularly miserable year in terms of security, starting shortly after Christmas with a number of zero-day exploits used high profile targeted attacks. Chrome, meanwhile, remains a difficult challenge for researchers and hackers alike. Not only is it a popular target during Pwn2Own, but Google runs a concurrent Pwnium event during the CanSecWest Conference challenging researchers to take a crack at the browser.
MWR Labs researchers were able to take down an up-to-date version of Chrome running on a fully patched Windows computer during the contest. Not only did they find and exploit a previously unknown flaw in Chrome, but were able to chain that together with a kernel exploit targeting Windows to elevate privileges and own the browser.
Meanwhile, James Forshaw, of Context Information Security of London, was able to break Java with an exploit for CVE-2013-1488, a vulnerability in the java.sql.DriverManager class, a trusted part of the Java framework, he wrote in a blogpost on Friday. This part of Java, he said, is used to access relational databases.
“Within the source code for this class, a Java vulnerability hunter would be drawn to the two AccessController.doPrivileged blocks like a moth to a flame,” he said. “They allow the Java libraries to temporarily elevate its privileges to perform a security critical action.”
Oracle released Java 7u21 last week with security patches that repaired all of the vulnerabilities exploited at Pwn2Own. Forshaw’s exploit enabled a sandbox bypass by repurposing unrelated code to ultimately disable the security manager and run malicious code as trusted. He said Oracle does not rate this flaw as critical because of the work involved, but a determined, persistent attacker could find success.
“That is also why I think something like Java can never be secured against hostile code running within a sandboxed environment,” Forshaw said. “The attacker has too much control to craft the environment to exploit the tiniest of weaknesses. The large amount of trusted code bundled with the JRE just acts to amplify that power.”
MWR Labs researchers, in turn, had to get equally creative to exploit the vulnerabilities in Chrome and beat the browser’s sandbox, as well as Chrome’s use of address space randomization layout (ASLR). The exploit targeted a WebKit vulnerability, which was the browser’s rendering engine, as well as a kernel overflow vulnerability in Windows, the underlying operating system.
The WebKit bug occurred in the way it handled viewing targets in Scalable Vector Graphics documents. SVG files support animation and interactive features on websites. MWR said in a blogpost it was able to specify a viewTarget for an SVG document and embed non-SVG elements inside a document.
“It is very difficult to secure such a complex piece of software, which frequently deals with untrusted input,” MWR said. “Even with modern exploit mitigation techniques and the inclusion of a sandboxed renderer processes, these protection mechanisms can be circumvented by exploiting the underlying operating system.”