Forwarded from BlackBox (Security) Archiv
How I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team exercise, trying to break into App Engine. This is the story of how I found a vulnerability and developed an exploit to break out of the App Engine sandbox and get arbitrary code execution on a Google server.
Background
One of the reasons I was skeptical was Java’s poor security track record. Java is unusual among programming languages in attempting to do in-process sandboxing with its Applet model, where trusted and untrusted code run within the same language runtime.
Back in the dark ages before Javascript and Webassembly took over the world, website authors that wanted to include nontrivial interactivity had to rely on browser plugins. Sun’s entry into the fray was Java Applets, a system that allowed website authors to include precompiled Java classfiles on their site. When the user views the embedding page, the browser sends that code to the Java Virtual Machine (JVM) installed on the user’s computer for execution.
In order to keep things secure, Java used a permission system to control what running code could and couldn’t do. Desktop applications were executed with all permissions by default, while Java applets ran with a very restrictive policy that prevented stuff like accessing the user’s local files.
Unfortunately, applets were still plagued with security vulnerabilities. One issue is that most of the Java runtime library is itself implemented in Java. Trusted and untrusted code run side by side in the same VM, with the only thing separating them being the permission system and visibility modifiers (public, protected, private, etc.)
This means that a bug anywhere in the JVM or standard libraries is liable to become a security vulnerability. Additionally, the attack surface is huge. The Java 7 runtime included over 17,000 classes, a lot of places for bugs to creep in.
https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-app-engine-anatomy-of-a-java-bytecode-exploit.html
#google #app #engine #hacked #java #bytcode #exploit
📡 @nogoolag 📡 @blackbox_archiv
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team exercise, trying to break into App Engine. This is the story of how I found a vulnerability and developed an exploit to break out of the App Engine sandbox and get arbitrary code execution on a Google server.
Background
One of the reasons I was skeptical was Java’s poor security track record. Java is unusual among programming languages in attempting to do in-process sandboxing with its Applet model, where trusted and untrusted code run within the same language runtime.
Back in the dark ages before Javascript and Webassembly took over the world, website authors that wanted to include nontrivial interactivity had to rely on browser plugins. Sun’s entry into the fray was Java Applets, a system that allowed website authors to include precompiled Java classfiles on their site. When the user views the embedding page, the browser sends that code to the Java Virtual Machine (JVM) installed on the user’s computer for execution.
In order to keep things secure, Java used a permission system to control what running code could and couldn’t do. Desktop applications were executed with all permissions by default, while Java applets ran with a very restrictive policy that prevented stuff like accessing the user’s local files.
Unfortunately, applets were still plagued with security vulnerabilities. One issue is that most of the Java runtime library is itself implemented in Java. Trusted and untrusted code run side by side in the same VM, with the only thing separating them being the permission system and visibility modifiers (public, protected, private, etc.)
This means that a bug anywhere in the JVM or standard libraries is liable to become a security vulnerability. Additionally, the attack surface is huge. The Java 7 runtime included over 17,000 classes, a lot of places for bugs to creep in.
https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-app-engine-anatomy-of-a-java-bytecode-exploit.html
#google #app #engine #hacked #java #bytcode #exploit
📡 @nogoolag 📡 @blackbox_archiv
Considerations on Codecrafting
How I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team…