A tweak carried out by Google in the Google App Engine for Java continues to stir up security concerns.
Oracle this week patched the latest vulnerability in Java SE-the flaw also lives in Google’s platform-as-a-service entry-after it was privately disclosed by Java bug-hunters from Security Explorations, a security consultancy in Poland.
The vulnerability addressed in the giant quarterly Critical Patch Update is another sandbox escape, the third such issue fixed since December.
This one, unlike the previous two, has its origin in Oracle code in the Java HotSpot Virtual Machine. HotSpot VM is core to Java and implements the Java VM specification, Oracle said. But because of a customization by Google, Security Explorations founder and CEO Adam Gowdiak said the vulnerability can be exploited “in a straightforward way” in Google App Engine.
“That’s due to the changes to Java security model Google decided to implement in its environment,” Gowdiak said, explaining that the change stems from Google’s decision to allow custom Class Loaders in Google App Engine.
“They are not allowed by standard Java security model (i.e. the one in use by Java Applets or Webstart applications) due to huge security risks associated with them,” Gowdiak said. “Many of the issues we discovered in GAE over the recent year were exploiting this ‘feature’ of Google App Engine.”
The vulnerability, Gowdiak said, is an improper initialization of non-public interface method slots leading to a partial security bypass in Java SE 7 and a complete sandbox bypass in Google App Engine.
“The vulnerability affects Google App Engine for Java and its first sandboxing layer (the sandbox Google built on top of JRE in order to prevent malicious Java apps from exploiting Java flaws),” Gowdiak said.
An attacker would need to use a specially crafted and malicious Java applet to exploit the vulnerability and escape both sandboxes.
“As a result, a lot of information about the JRE sandbox itself, Google internal services and protocols could be gained by an attacker (the middleware layer whole Google runs on),” Gowdiak explained. “The vulnerability also seems to be a good starting point to proceed with attacks against the OS sandbox and RPC services visible to the sandboxed Java environment.”
Oracle’s quarterly patch update was released Tuesday night, and as usual, it was a monster update. Admins were presented with 154 vulnerabilities in 54 products across the Oracle line; more than half of those vulnerabilities could be exploited remotely without authentication, Oracle said.
The HotSpot VM vulnerability was one of two dozen patched by Oracle in Java SE; seven of which are rated critical by Oracle and could lead to full compromise.
In May, Security Explorations disclosed details and proof of concept code for three Java sandbox escapes stemming from vulnerabilities in the Google App Engine for Java. Those flaws were likely patched in a silent fix sent out by Google; Security Explorations’ PoC code stopped working in production versions of Google App Engine without confirmation of a patch from Google, Gowdiak said at the time.
In December, Security Explorations reported more than 30 vulnerabilities in GAE, some that enable remote code execution or sandbox escapes. However, the company’s test account was suspended at the time, preventing the researchers from finishing their analysis of GAE at the time.
“Without any doubt this is an opsec failure on our end (this week we did poke a little bit more aggressively around the underlying OS sandbox/issued various system calls in order to learn more about the nature of the error code 202, the sandbox itself, etc.),” Gowdiak said in a post to the Full Disclosure security mailing list.
