GAE Java security sandbox bypasses

2015.05.07
Credit: Adam Gowdiak
Risk: Medium
Local: Yes
Remote: No
CVE: N/A
CWE: N/A

Hello All, Security Explorations released technical details and POC codes for additional security vulnerabilities found in Google App Engine for Java. All relevant materials can be found at our SE-2014-02 project details page: http://www.security-explorations.com/en/SE-2014-02-details.html The above link contains technical description of the following four weaknesses discovered after initial 31 issues were patched by Google in March 2015: - Issues 32-33 (missing safeDefineClass methods in SafeClassDefine implementation), they are similar to previously reported Issues 12 and 14 [1], - Issue 34 (missing security check in the implementation of a bind method of MethodHandles.Lookup mirror class), - improperly patched Issue 2 #2 (java.net.URLClassLoader instantiation via java.security.Provider.Service). These issues could be easily exploited to gain a complete GAE for Java security sandbox escape. Google hasn't provided us with a status report regarding successful resolution of these weaknesses in its production GAE, but we have observed that the POCs exploiting them stopped working. According to our Disclosure Policy [2], that alone constitutes a sufficient condition for a publication of the issues. It's worth to note that a POC for Issue 2 #2 makes use of previously reported Issues 19 and 22. Issue 19 was evaluated by Google as working as intended (WAI) issue. Issue 22 should have been fixed, but this hasn't been done (a status report from Google received on 04-Mar-2015 stated that all issues, except Issue 21, are fixed and shouldn't work anymore [3]). It is likely due to Google's vulnerability evaluation methodology focused on a root cause tracking. We have warned Google that by focusing on the so called root cause, it could easily miss an innocent vulnerability that may turn out to be helpful in a future attack. We didn't need to wait long for that to happen. Apart from Issue 22, we have also found out that Issues 23, 25, 26 and 27 have not been addressed by Google either (they could be also successfully chained with Issues 2 #2 and 19 for a complete GAE Java security sandbox escape). Google stated that it considered them as working as intended issues (not exploitable except in conjunction with other issues). It's however interesting that the company has indicated that it may remove some of those [vulnerable] classes from its runtime jar in the future. We have also released a POC code for Issue 21. This is a very minor modification of our POC for Issue 69 of SE-2012-01 project [4] that was published in Oct 2013. This POC proved that: - GAE for Java could be successfully hacked with the use of a public vulnerability / exploit code from Oct 2013 till Mar 2015, - Issue 21 (1.5+ years old JRE) could be successfully exploited contrary to Google's claim that GAE has "mitigations in place that prevent the issue from being exploitable" ([3] 04-Mar-2015). Finally, it's also worth to mention that there are three additional complete GAE sandbox escape POCs (Issues 35-41) that still require addressing and confirmation (Issues 37-41 in particular) from Google. Thank you. Best Regards, Adam Gowdiak --------------------------------------------- Security Explorations http://www.security-explorations.com "We bring security research to the new level" --------------------------------------------- References: [1] "Google App Engine Java security sandbox bypasses", technical report http://www.security-explorations.com/materials/se-2014-02-report.pdf [2] Disclosure Policy http://www.security-explorations.com/en/disclosure-policy.html [3] SE-2014-02 Vendors status http://www.security-explorations.com/en/SE-2014-02-status.html [4] SE-2012-01 Security vulnerabilities in Java SE http://www.security-explorations.com/en/SE-2012-01.html

References:

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


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top