Date: Mon, 16 Mar 2015 08:32:36 +0100
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, fulldisclosure@...lists.org
Subject: [SE-2014-02] Google App Engine Java security sandbox bypasses (details)


Hello All,

Details of our SE-2014-02 project have been released to the public.
A technical writeup and accompanying Proof of Concept codes can be
found at the following location:

http://www.security-explorations.com/en/SE-2014-02-details.html

In case of Google App Engine for Java, its first layer of defense
was built around a Java VM sandbox. Google decided to implement
an additional security layer (sandbox) on top of it. As a result,
several custom security measures were integrated into a Java VM
runtime. This in particular concerns the Class Sweeper, of which
goal was to verify and transform untrusted user code into a
corresponding, safer representation. The API Interception and
Interjection mechanism was meant to enforce proper security checks
in runtime for security sensitive Java SE API calls. Finally,
the JRE Class Whitelisting was supposed to limit the scope of
Java classes visible to user applications.

Unfortunately, the custom security layer implemented by Google
turned out to be vulnerable to multiple security weaknesses. Some
of them were instances of known vulnerabilities published in the
past. This in particular concerns the issues disclosed as part of
SE-2012-01 research affecting Java SE implementation from Oracle
and IBM (Issues 4, 9 and 31). This also concerns several security
vulnerabilities that made it possible to break Oracle Java Cloud
Service (Issues 1 and 4). The ability to break GAE with the use
of a prior research indicates that it was either ignored or simply
never taken into account.

The majority of the flaws discovered in GAE were related to
either Reflection API or Class Loaders. These were rather
simple issues, which should have been caught during a security
review process preceding a release of GAE software (or any major
update to it). Reflection API and Class Loaders are fairly
complex and security sensitive components of a Java VM. A lot
of expert knowledge and a deep understanding of their operation
is usually required prior to introducing any changes to them
without jeopardizing the security of a JVM. Regardless of that,
Google decided to "reimplement" Java Reflection API, through
the GAE interception layer. This was the same API that caused
so much trouble for Oracle in the recent years and that was
responsible for dozens of security issues in Java. The company
also allowed for a creation of arbitrary user provided Class
Loaders in GAE, which immediately created a need to protect the
environment from these objects.

As a result, a security model of a standard JRE was weakened
(Issue 17-19). Arbitrary vulnerabilities were introduced on
top of the implementation of JRE API calls (Issues 3 and 5),
which GAE Java API interception model aimed to protect. These
vulnerabilities constituted the same violations of Java Secure
Coding Guidelines [1] of which Oracle has been usually accused
of. Many vulnerabilities had its origin in an incomplete
interception of Java SE 7 method handles API (Issues 7, 9, 11,
15, 16), Class Loader's operation (Issue 13) or mitigations
aimed at making user Class Loaders less privileged than usual
(Issues 8, 10, 12, 14).

During our correspondence with Google, the company often
emphasized that we only broke the first layer of defense and
that it considered the remaining, lower sandboxing layers
sufficiently robust. This could explain why the environment
of a cloud computing platform from Google ran on a 1+ year
old Java runtime (Issue 21). However, the amount and nature
of information leaked by the first sandboxing layer along
with the company's preference not to have the details of the
next sandboxing layers published seemed to contradict the
confidence expressed regarding their robustness.

It should be also mentioned that regardless of a successful
detection of our activity in GAE, Google's ability to detect
attacks in the environment was not perfect. Our activity
raised an alarm 2 years after an initial GAE security sandbox
compromise. It was likely detected because we decided to launch
more aggressive (more visible / risky) tests and did not follow
our usual, low-profile pattern of activity.

Google is a specific software vendor that serves hundreds of
millions of users on a daily basis through its custom services.
In most cases, the architecture and implementation details of
these services are not known due to their server-side nature.
As a result, the ability to discover security issues in these
services could be quite challenging. Without any doubt security
of Google services is not less important than discovering
vulnerabilities in a client / server side software of other big
software vendors. That thought alone should catch attention
of Google itself. At the end of a day, it might turn out that
it would be of a more benefit to the company and users of its
services to have Google security personnel to be more focused
on its own products instead of the products of the competition
[2]. The case of Google App Engine for Java shows that this
might actually make sense and that there are still places for
improvement in Google's own yard.

Thank you.

Best Regards,
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

References:
[1] Secure Coding Guidelines for Java SE
     http://www.oracle.com/technetwork/java/seccodeguide-139067.html
[2] Project Zero
     http://googleprojectzero.blogspot.com/

Powered by blists - more mailing lists