full-disclosure - [FD] [SE-2014-02] Google App Engine Java security sandbox bypasses (Issue 42)

Open Source and information security mailing list archives

Date: Wed, 21 Oct 2015 09:53:00 +0200
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, fulldisclosure@...lists.org
Subject: [FD] [SE-2014-02] Google App Engine Java security sandbox bypasses
 (Issue 42)

Hello All,

Oracle Critical Patch Update released yesterday incorporates a fix
for a Java SE 7 vulnerability (Issue 42) that was discovered while
investigating security of Google App Engine. Its technical details
and a POC code can be found at the following address:

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

Issue 42 is caused by improper initialization of interface method
slots in a HotSpot VM. As a result, protected instance methods can
be successfully used as interface methods. This violates the Java
Virtual Machine Language Specification [1], which states that "if
the selected method is not public, invokeinterface should throw an
IllegalAccessError".

GAE weakens standard Java security model by allowing custom Class
Loaders. In order to protect against direct exploitation of this
"feature", access to defineClass methods of java.lang.ClassLoader
class and it subclasses is restricted in Google environment [2].
Issue 42 can be used to directly invoke such methods with the use
of interfaces. As a result, user provided classes can be defined
outside of a GAE Class Sweeper sandbox and Java security manager
can be completely turned off.

It's also worth to note that in Mar 2015, Google indicated that it
"has other mitigations in place that prevent Issue 21 [1+ years
old JRE with 100+ unpatched security vulnerabilities] from being
exploitable". This is the second time we show these mitigations are
not working as intended [3]. What is however more interesting is
that rather mediocre Java SE issue can be successfully exploited
in a straightforward way in GAE environment, just because Google
has chosen to "tweak" a standard Java security model a little bit.

Thank you.

Best Regards,
Adam Gowdiak

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

References:
[1] The Java Virtual Machine Specification, Java SE 7 Edition
     http://docs.oracle.com/javase/specs/jvms/se7/html/
[2] "Google App Engine Java security sandbox bypasses", technical report
     http://www.security-explorations.com/materials/se-2014-02-report.pdf
[3] Proof of Concept Code for Issue 21 (POC23)
     http://www.security-explorations.com/materials/se-2014-02-32-34.zip

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives