Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Custom Google App Engine Tweak Still Leads to Java Sandbox Escapes

Researchers at Security Explorations say a change implemented by Google to the Java security model as its implemented in the Google App Engine leads to sandbox escapes.

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.

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 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.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.