Google App Engine for Java

General info

In a result of its research investigation efforts, Security Explorations discovered multiple security vulnerabilities in Google App Engine for Java.

This section of our website presents initial information regarding the project that lead to this discovery:

  • Official press statement containing general information about the research and Google award.
  • Frequently Asked Questions about our discovery.
  • Technical details of conducted attacks and security issues found.
  • Status of the communication with vendors of affected technologies.

Project newsroom

Google App Engine for Java - Press Info no. 2
21
JAN 2016

Google App Engine for Java - Press Info no. 2

Security Explorations' founder and CEO, Adam Gowdiak will give a keynote talk at JavaLand Conference in Bruhl [1] in Mar 2016 (...)

Read more
Google App Engine for Java - Press Info no. 1
29
DEC 2014

Google App Engine for Java - Press Info no. 1

Security Explorations, a security and vulnerability research company from Poland receives a reward from Google for discovering security issues (...)

Read more

FAQ

What motivated you to look into Google App Engine (GAE) for Java [1]?

We wanted to verify whether security and privacy of users' data and applications is properly implemented in the environment of an arbitrary cloud service based on a Java VM runtime.

We also wanted to find out whether security issues similar to those discovered in Java SE software were present in other vendors' code.

How long did you work on this project?

The project was started in Oct 2012. Due to the fact that we conducted 3 other non-commercial research projects (SE-2012-01, SE-2013-01 and SE-2014-01) in the meantime, our GAE work needed to be postponed several times. We finally came back to it in Oct 2014.

Is the project complete?

We treat it as complete. Google made it possible for us to complete the project. The company enabled our suspended account and we were able to verify and test our ideas / codes in a GAE environment again.

What do you think about Google's action letting you complete your work?

We have high respect to Google for this move and truly appreciate it. If Google wouldn't let us complete the work, we'd have wasted months of research.

Google's move makes it possible for all parties interested in a security of Java and Java cloud based solutions such as PaaS to benefit from the results of our work (it makes contribution to the field possible).

What's the impact of the vulnerabilities found?

We found multiple issues that allow for a bypass of certain GAE security restrictions such as the whitelisting of JRE classes and/or a complete escape of a Java VM security sandbox.

Do they pose any risk to other GAE user's data or applications?

We haven't reached a point in our research where we could state that arbitrary compromise of other GAE user's data or applications is possible.

Did any of the vulnerabilities discovered affect Oracle Java SE software?

Almost all vulnerabilities found are specific to the GAE environment. None of the implemented, complete Java security sandbox escapes affect Oracle Java software.

We used a minor issue in Oracle Java code to implement a given instance of a JRE classes whitelisting escape (Issue 2), but it was evaluated by Oracle as not affecting Java SE.

We also discovered a partial security bypass issue in Java SE 7 code, which was accepted by Oracle (Issue 42) and demonstrated a complete GAE Java security sandbox escape with it.

How come a partial Java security bypass vulnerability could lead to a full sandbox escape in GAE?

Issue 42 can be exploited in a straightforward way in GAE environment, because Google decided to change a standard Java security model for it (allow for custom Class Loaders in particular). As a result, it was possible to access full functionality of these objects (i.e. define privileged classes without any restrictions) and disable Java security mechanisms for the GAE environment.

Beside illustrating the pitfalls associated with custom Java Runtime modifications applied by the company to security sensitive Java APIs and components, Issue 42 also showed that Google mitigations aimed at preventing the exploitation of JRE flaws were not working as intended.

Is there anything specific about discovered vulnerabilities?

Yes. Discovered security issues violate "Secure Coding Guidelines for the Java Programming Language" [2]. They also illustrate very known risks related to Java security [3].

What an attacker could accomplish with the use of the issues found?

They could be used to gain a lot of information about the JRE sandbox itself, Google internal services and protocols.

They also seem to be a potentilly good starting point to proceed with attacks against the OS sandbox and RPC services visible to the sandboxed Java environment.

Did Google communicate to the public the fixing of the reported issues?

We are not aware of any such communication. In that context, we are the only source of information to the public regarding these issues.

Do you expect a reward for you research from Google [4]?

Over the last 6 years of our activity we have found dozens of security issues that affected hundreds of millions of people (just to mention Oracle Java flaws) or devices (security issues in STMicroelectronics' set-top-box chipsets).

We have never received any reward from any vendor for our work and we didn't expect any reward this time either. But, we have received a reward from Google. More on that can be read here

It's worth to note that Google rewarded Issues 1-27 reported to the company in Dec 2014. The company also issued two additional rewards for the vulnerabilities reported in the first half of 2015 ($20000 for Issues 28, 31-34 and improperly fixed Issue 2 and $30000 for Issues 35-39 and 41). As a result, the total amount of rewards issued by Google for security vulnerabilities discovered in GAE environment has reached $100000.

Will you be publishing the results of your research?

Yes. All vulnerabilities' details and Proof of Concept codes have been published here.

References:

Details

This page presents details of security vulnerabilities and attack techniques discovered as a result of our Google App Engine for Java security research project. These details are provided in a form of a technical report and accompanying Proof of Concept Codes.

Materials

  • "Google App Engine Java security sandbox bypasses", technical report, PDF file, 2.9MB (download)

Google Vulnerability Reports

  • SE-2014-02-GOOGLE, Issues #32-34, PDF file, 222KB (download)
  • SE-2014-02-GOOGLE-2, Issue #2(#2), PDF file, 272KB (download)
  • SE-2014-02-GOOGLE-3, Issues #35-36, PDF file, 245KB (download)
  • SE-2014-02-GOOGLE-4, Issues #37-39, PDF file, 241KB (download)
  • SE-2014-02-GOOGLE-5, Issue #40, PDF file, 218KB (download)
  • SE-2014-02-GOOGLE-6, Issue #41, PDF file, 210KB (download)

Oracle Vulnerability Reports

  • SE-2014-02-ORACLE, Issue #42, PDF file, 235KB (download)
  • SE-2014-02-ORACLE Errata, Issue #42, PDF file, 510KB (download)

Google Vulnerability Research Grant (failed GAE hacking attempt, 2018)

  • Google Vulnerability Research Grant report, PDF file, 2405KB (download)

Additionally, the slides for a keynote talk given at JavaLand conference in 2016 are also provided. This talk referred to SE-2014-02 and our other research projects while discussing key problems related to Java platform security, its ecosystem and vendors.

  • "Java (in)security", PDF file, 1.4MB (download)

DISCLAIMER

Proof of Concept Codes below are provided purely for educational purposes only. It is expressly forbidden to use them for any purposes that would violate any domestic or international laws. If you do not agree with this policy, please leave this page.

  • "Google App Engine Java security sandbox bypasses", Proof of Concept codes, ZIP file, 299KB (download)
  • "Google App Engine Java security sandbox bypasses", Proof of Concept codes for Issues 32-34, ZIP file, 144KB (download)
  • "Google App Engine Java security sandbox bypasses", Proof of Concept codes for Issues 35-41, ZIP file, 97KB (download)
  • "Google App Engine Java security sandbox bypasses", Proof of Concept code for Issue 42, ZIP file, 31KB (download)

Vendors

This page presents current status of the communication process with vendors of affected technologies.

Summary of the communication process:

  • 06-Dec-2014
- As a result of the inability (suspended account) to complete its research, Security Explorations informs Google and general public about SE-2014-02 research project and a discovery of multiple security issues in Google App Engine for Java.
- Google responds that the company is interested to hear more about the vulnerabilities found.
- Security Explorations informs Google that it would need a couple of more days to work on the project in order to bring it up to the usual quality when reporting issues to vendors. The company asks Google whether it would be able to lift the suspension from its GAE account.
  • 07-Dec-2014
- Google responds that it would appreciate to get whatever information Security Explorations has on the vulnerabilities now. The company informs that it generally encourages external researchers to stop as soon as they find a vulnerability, and let Google take it from there. Google also informs that it will check how to go about re-enabling suspended GAE account.
- Information regarding vulnerabilities and associated PoC codes are sent to Google (Issues 1-22 / unconfirmed Issues 23-35).
  • 08-Dec-2014
- Google confirms successful reception and decryption of the received material. The company informs that it will investigate based on the data provided and get back once it has got any update.
- Oracle inquiries whether any security issues found in Google App Engine affect its products.
- Security Explorations informs Oracle that most of the issues are specific to Google environment. The company provides Oracle with brief information and a Proof of Concept Code for a minor issue having its origin in Oracle Java code (Issue 2).
  • 09-Dec-2014
- Oracle provides a tracking number for the reported issue.
  • 10-Dec-2014
- Google informs that it has been looking into the report and that the company has been able to reproduce the issues locally, but when tried in production some of them didn't seem to work. Google asks Security Explorations about the methodology used to test in production.
- Security Explorations informs Google that it didn't manage to test the codes from its local GAE environment in production. The company provides information regarding the methodology used for setting up the local GAE environment for POC codes development. Security Explorations asks Google to provide the output of a simple Java code executed in GAE.
  • 11-Dec-2014
- Google informs Security Explorations that it is OK for the company to continue the research as long as it is done within the JVM and not moved on to the next sandboxing layer. Google indicates that it would not like the details of the next sandboxing layer as well as the details of its monitoring capabilities to be public knowledge.
- Google delivers the output of the code requested by Security Explorations.
- Security Explorations agrees to Google proposal and informs the company that it will continue its research with a scope limited to GAE Java VM layer.
- Google informs Security Explorations that its test GAE account has been re-enabled.
  • 12-Dec-2014
- Security Explorations provides Google with 3 POC codes and brief information regarding Issues 1-4.
- Google confirms successful reception and decryption of the received material.
  • 13-Dec-2014
- Security Explorations provides Google with 4 POC codes and a brief information regarding Issues 5-9.
  • 15-Dec-2014
- Security Explorations provides Google with 9 POC codes and a brief information regarding Issues 10-21.
- Google confirms successful reception and decryption of the received material.
  • 17-Dec-2014
- Oracle engineering team inquiries about how Issue 2 might be used to bypass security checks in Oracle code.
  • 18-Dec-2014
- Security Explorations responds that it never stated that Issue 2 could be used to bypass security checks in Oracle code, but rather that Oracle code sequence could be an issue if some whitelisting is enforced in a given environment (such as GAE). The company asks Oracle whether it should be assumed that Issue 2 is not a security bug in Oracle code, but rather in Google code.
  • 19-Dec-2014
- Security Explorations provides Google with a POC code and a brief information regarding Issue 22.
- Google confirms successful reception and decryption of the received material. The company informs that some fixes are to be going out soon.
  • 20-Dec-2014
- Security Explorations provides Google with a POC code and a brief information regarding Issue 23.
- Security Explorations asks Google whether the company can officially confirm any of the reported issues.
  • 22-Dec-2014
- Security Explorations provides Google with a POC code and a brief information regarding Issues 24-27.
- Security Explorations changes classification of Issue 24. The company provides Google with a modified POC code for it illustrating a complete Java security sandbox escape.
  • 23-Dec-2014
- Google confirms successful reception and decryption of the received material. As a response to the vulnerabilities confirmation request, the company states that it has been making a lot of changes based on a report, including for the issues that didn't work [those tested in a local GAE environment only], that some of the issues that worked turned out to have as a root cause a common bug / class with a couple different exploitation vectors. Google acknowledges that Security Explorations' report demonstrated that one of company's layers of defense had insufficient mitigations against certain type of attacks and the auditing of the privileged Java classes were insufficient.
- Security Explorations informs Google that it would like to know, which issues are confirmed, denied or treated as duplicates as this will make it possible for all interesting parties to track Google's progress aimed at a resolution of the reported weaknesses. The company asks Google to limit the above information to the issues confirmed in production after its GAE account was reenabled (Issues 1-27, reported since Dec 12, 2014).
  • 24-Dec-2014
- Oracle provides a monthly status report for the reported issues. The company informs that Issue 2 is under investigation / being fixed in main codeline.
- Google provides a comprehensive status report regarding reported issues. The company informs that for the issues reported since Dec 12, 2014, 23 weaknesses have been accepted and 4 are work as intended (WAI) issues (not a bug). Google also informs that Issues 1-4, 13 have been fixed and that the company is interested to hear feedback regarding WAI issues (Issues 17-20).
  • 25-Dec-2014
- Google provides additional information to its status report. The company informs that it filled 16 bugs (3 marked as won't fix), 5 bugs are actively worked on and the rest are fixed although not all pushed to production.
  • 27-Dec-2014
- Security Explorations provides Google with arguments regarding WAI Issues 17-20 explaining their classification as security vulnerabilities. The company informs Google that it does not agree with its vulnerabilities' evaluation methodology ("the issues that worked turned out to have as a root cause a common bug / class with a couple different exploitation vectors") and that it will continue to track reported issues using its original numbering scheme.
- Security Explorations provides Google with a POC code and a brief information regarding Issues 28-30.
  • 29-Dec-2014
- Google confirms successful reception and decryption of the received material. The company informs that it will get back soon on the feedback provided.
  • 31-Dec-2014
- Security Explorations provides Google with a modified code for Issue 5 and additional information regarding WAI Issues 17 and 18.
  • 06-Jan-2015
- Google informs that Issue 28 was accepted. The company states that it generally agrees that certain WAI Issues are deviations from the traditional java security model, but indicates that it was necessary (dealing with web applications vs. java applets). Google informs that it is considering adding several additional hardening checks and mechanisms, that while not map 1-to-1 to Security Explorations' recommendations, should provide an equivalent level of security.
  • 13-Jan-2015
- Google informs that the company is getting ready to verify some of the fixes and evaluate the prioritization of some of the mitigations.
- Security Explorations provides Google with a POC code and a brief information regarding Issue 31.
  • 16-Jan-2015
- Oracle informs that its engineering team reviewed Issue 2 and came to conclusion that this is not an issue for Java SE. Thus, the company will close Issue 2.
  • 19-Jan-2015
- Google confirms successful reception and decryption of the received material.
  • 02-Mar-2015
- A request for a status update information regarding the fixing of the reported issues is sent to Google.
  • 03-Mar-2015
- Google responds that most of the changes the company wanted to make are done. The company informs that it has been making changes across the whole platform. Google has two "important" open tasks left which it is still actively working on along with many other lower-priority tasks that are still pending to be started.
  • 04-Mar-2015
- Security Explorations informs Google that it is not clear from the message received whether all reported issues have been fixed. The company asks Google for a more precise information regarding their fixing status (Issue #, fixed / fix in development, etc.).
- Google responds that all issues, except Issue 21, are fixed and shouldn't work anymore. Several engineers have been working on Issue 21 for a while, but because of the way GAE works, addressing it is a very slow process that requires a lot of manual work. Google informs that a company has other mitigations in place that prevent the issue from being exploitable.
  • 17-Mar-2015
- Security Explorations informs Google that its mitigations preventing Issue 21 from being exploitable do not work as intended. The company provides Google with a proof illustrating that. Security Explorations also informs Google that its patched GAE environment leaks even more data about Google internals than in Dec 2014. This includes security sensitive GAIA data containing login configuration for some of Google's customer networks among others.
- Google informs that it is aware that Issue 21 can be used to read files outside of the JVM sandbox, but the company has deemed it an acceptable risk for now until the JVM can be upgraded. With respect to the GAIA configuration file, Google informs that the information it includes isn't secret or sensitive, but it should not be present in GAE.
- Google informs that another fix for Issue 21 was deployed in GAE and that a POC exploiting it should not work anymore.
  • 18-Mar-2015
- Security Explorations asks Google to look into the specific GAIA frontend configuration file and to confirm whether "the information there isn't secret or sensitive". The company asks for the same with respect to another GAIA file.
  • 20-Mar-2015
- Google provides a more detailed explanation of the contents of the GAIA files. The company informs that although they might give the appearance of being sensitive, they are not from a security perspective. The company also informs that it is taking this as an opportunity to re-review the contents of the jar file(s) to determine if any exposures exist.
- Vulnerability Notice along with Proof of Concept codes are sent to Google corporation (Issues 32-34).
  • 22-Mar-2015
- Vulnerability Notice along with a Proof of Concept code are sent to Google corporation.
  • 23-Mar-2015
- Google confirms successful reception and decryption of the received material.
  • 28-Mar-2015
- Security Explorations asks Google for information when the reported issues are confirmed.
  • 01-Apr-2015
- Security Explorations provides Google with additional details and a Proof of Concept code for the vulnerability report from Mar 22, 2015.
  • 03-Apr-2015
- Security Explorations asks Google whether it needs any assistance in running the received Proof of Concept Codes or whether a confirmation of reported vulnerabilities from a 3rd party such as US-CERT would be helpful for the company. Security Explorations informs Google that it expects a clear confirmation or denial of the reported issues, regardless of their fixing status.
  • 07-Apr-2015
- Google responds that it has been able to successfully run all of the POCs supplied. The company confirms all reported Issues (32-34 in particular) and informs that unfixed Issues 22, 23, 25, 26 and 27 from Dec 2014 are working as intended (not exploitable except in conjunction with other issues, the company may however remove some of those classes from its runtime jar in the future).
  • 15-Apr-2015
- Vulnerability Notice along with a Proof of Concept code is sent to Google corporation (Issues 35 and 36).
- Google confirms successful reception and decryption of the received material.
  • 19-Apr-2015
- Vulnerability Notice along with a Proof of Concept code is sent to Google corporation (Issues 37-39).
  • 21-Apr-2015
- Vulnerability Notice along with a Proof of Concept code is sent to Google corporation (Issue 40).
- Google confirms successful reception and decryption of the received material.
  • 23-Apr-2015
- Vulnerability Notice along with a Proof of Concept code is sent to Google corporation (Issue 41).
  • 28-Apr-2015
- Security Explorations asks Google whether it needs any assistance in running the received Proof of Concept Codes or whether a confirmation of reported vulnerabilities from a general public (Bugtraq / Full Disclosure mailing lists' subscribers) would be helpful for the company. Security Explorations informs Google that it expects a clear confirmation or denial of Issues 35-39 reported nearly 2 weeks ago, regardless of their fixing status. Security Explorations also asks Google for a confirmation of a successful reception and decryption of the vulnerability report from Apr 23, 2015 (Issue 41).
  • 29-Apr-2015
- Google confirms successful reception and decryption of the material describing Issue 41. The company informs that it will get back to us shortly regarding the confirmation of the reported issues.
  • 06-May-2015
- Security Explorations informs Google that 3 weeks after reporting Issues 35 and 36 no official confirmation / denial was received from the company with respect to them. Security Explorations also informs Google that historically, unconfirmed or denied issues were the subject to an immediate release without a prior notice to the vendor and that it should not take more than 1-2 business days for Google (and its Security Team consisting of hundreds of security engineers in particular) to run the received POC, read the report and / or consult the source code. Security Explorations notifies Google that having unconfirmed vendor status, Issues 35 and 36 are due to be released shortly. The same will apply to Issues 37-41 if they remain unconfirmed beyond the 3 weeks time.
- Google confirms Issues 35 and 36. The company informs that it will provide update on the remaining issues when it has more information.
  • 11-May-2015
- Google confirms that it was able to execute Proof of Concept codes illustrating Issues 37-41.
  • 16-May-2015
- Google provides a status update for the reported issues. The company informs that a fix is scheduled to be rolled out soon for Issues 35-36 and that it is testing fixes for Issues 37, 38, 39 and 41. The latter fixes were scheduled for production deployment in a subsequent release, but Google is now considering pulling these forward. The company also informs that Issue 40 was not addressed at this time because it is of substantially lower security concern. With respect to the disclosure of Issues 35-41, Google proposes several steps to get back on track regarding the handling of Security Explorations' vulnerability reports. The company will resurrect the tracking sheet that had been established in the initial round of issues, and will use that as the primary means of providing Security Explorations with the most up to date information. Google will proactively send out emails when a new report is successfully decrypted and when it has determined if there is a vulnerability (or not) and when it considers the issue fixed. Google also clarifies that the disclosure of issues 35-41 will have no bearing on previous awards in the VRP.
  • 28-May-2015
- Google provides a comprehensive, cumulative status report regarding reported issues. The company informs that for the issues reported since Dec 27, 2014, 12 weaknesses (Issues 28-39) have been accepted and fixed. Issues 40-41 have been also accepted, but are not fixed yet (resolved internally on May 15, 2015).
  • 25-Jun-2015
- A request for a status update information regarding the fixing of Issues 40 and 41 is sent to Google.
- Google responds that the company does not plan to take any action for Issue 40 and that the fix for Issue 41 was deployed in production.
  • 26-Jun-2015
- Google provides an updated version of the tracking sheet. It indicates that Issue 40 has been evaluated as working as intended (WAI) issue.
  • 30-Jun-2015
- Vulnerability Notice along with a Proof of Concept code is sent to Oracle corporation (Issue 42).
- Oracle confirms successful reception and decryption of the vulnerability report. The company informs that it will investigate based on the data provided and get back to us soon.
- Oracle provides a tracking number for the reported issue.
  • 07-Jul-2015
- Oracle confirms Issue 42. The company informs that it will be addressed in a future Java release.
  • 24-Jul-2015
- Oracle provides a monthly status report for the reported issue. The company informs that Issue 42 is under investigation / being fixed in main codeline.
  • 24-Aug-2015
- Oracle provides a monthly status report for the reported issue. The company informs that Issue 42 is fixed in main codeline and is scheduled for a future CPU.
  • 24-Sep-2015
- Oracle provides a monthly status report for the reported issue. The company informs that Issue 42 is fixed in main codeline and is scheduled for a future CPU.
  • 17-Oct-2015
- Oracle provides a status report regarding upcoming CPU. The company informs that a fix for Issue 42 will be incorporated into Critical Patch Update, due to be released on October 20, 2015.
  • 23-Oct-2015
- Oracle provides a status report for the reported issues. The company informs that Critical Patch Update was released with a fix for Issue 42.
  • 29-Oct-2015
- Security Explorations asks Google for CVE numbers corresponding to vulnerabilities reported as part of SE-2014-02 project (Issues 1-41) and links / references to information published by the company communicating their fixing.
  • 30-Oct-2015
- Security Explorations asks Oracle for a CVE number corresponding to Issue 42.
- Oracle informs that it will gather the requested information and get back to us.
  • 31-Oct-2015
- Google responds that GAE vulnerabilities don't qualify for CVE identifiers as GAE is a service that is not publicly released or packaged in code or binary form. The company informs that per information received from MITRE, CVE IDs are not for cases in which the primary method of addressing the vulnerability is for an action to be taken by the operator of a single web site or online service. As for the links / references to information published by the company communicating the fixing of the weaknesses, Google informs that it does not currently have anything like that.
  • 02-Nov-2015
- Oracle provides a CVE number for Issue 42.
  • 09-Dec-2015
- Google briefly informs Security Explorations about new "hardened" version of a sandbox and the approach taken to it (removal of the security manager and the bytecode rewriter in particular, focusing on adding a couple more sandboxing layers on top of Java).
  • 03-Oct-2016
- Security Explorations inquires Google whether the new "hardened" sandbox was enabled in a production GAE (the tests conducted revealed that Java Security Manager was still present in GAE).
- Google responds that the company deprecated the sandbox and replaced it with another containment technology that lives outside of the JVM. Google informs that it doesn't consider the Java Sandbox a first-layer of defense anymore and already started to decline fixing Java Sandbox escapes going forward. The company also stated that it is working on fully disabling the sandbox, which will be done together with a JDK upgrade that is in progress.
  • 25-Aug-2017
- Security Explorations informs Google that the tests conducted revealed that Java Security Manager was still present in GAE. The company asks Google for clarification regarding previous statements and inconsistent Java security sandbox status in GAE.
- Google responds that java sandbox should be completely disabled in new (Java 8) runtimes. The company clarifies that for old (Java 7) runtimes, the security manager wasn't removed in order not to accidentally break applications, but it's not used as a security boundary anymore and can be completely bypassed by just running Java 8 directly.