bugtraq - [SE-2014-02] Google App Engine Java security sandbox bypasses (project pending completion / action from Google)

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <548322A6.5030309@security-explorations.com>
Date: Sat, 06 Dec 2014 16:37:10 +0100
From: Security Explorations <contact@...urity-explorations.com>
To: security@...gle.com
CC: fulldisclosure@...lists.org, bugtraq@...urityfocus.com
Subject: [SE-2014-02] Google App Engine Java security sandbox bypasses (project
 pending completion / action from Google)


Hello All,

We discovered multiple security issues in Google App Engine that allow
for a complete Java VM security sandbox escape.

There are more issues pending verification - we estimate them to be in
the range of 30+ in total.

Quick summary of our developments so far:
- we bypassed GAE whitelisting of JRE classes / achieved complete Java VM
   security sandbox escape (17 full sandbox bypass PoC codes exploiting 22
   issues in total),
- we achieved native code execution (ability to issue arbitrary library
   / system calls),
- we gained access to the files (binary / classes) comprising the JRE
   sandbox, that includes the monster libjavaruntime.so binary (468416808
   bytes in total),
- we extracted DWARF info from binary files (type information and such),
- we extracted PROTOBUF definitions from Java classes (description of 57
   services in 542 .proto files),
- we extracted PROTOBUF definition from binary files (description of 8
   services in 68 .proto files),
- we analyzed the above stuff and learned a lot about the GAE environment
   for Java sandbox (among others).

Unfortunately, we cannot complete our work due to the suspension of the
"test" GAE account that took place today.

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

Taking into account an educational nature of the security issues found
in GAE Java security sandbox and what seems to be an appreciation Google
has for arbitrary security research / all sorts of sandbox escapes [1],
we hope the company makes it possible for us to complete our work and
reenables our GAE account, so that we could in particular:
- verify the remaining potential vulnerabilities spotted,
- verify some attack ideas,
- prepare short report containing the description of the issues found
   (the results of the evaluation) and deliver it to Google (in a form
   similar to SE-2013-01 project report [2]),
- share the results of our research with the security community.

Thank you.

Best Regards,
Adam Gowdiak

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

References:
[1] Google Security Research
     http://code.google.com/p/google-security-research/
[2] Security vulnerabilities in Oracle Java Cloud Service
     http://www.security-explorations.com/en/SE-2013-01.html