Presentation on theme: "Joshua J. Drake Inaugural InfoSec Southwest March 31 st 2012 Exploiting Memory Corruption Vulnerabilities in the Java Runtime."— Presentation transcript:
Joshua J. Drake Inaugural InfoSec Southwest March 31 st 2012 Exploiting Memory Corruption Vulnerabilities in the Java Runtime
About the Presenter Joshua J. Drake, aka jduck – Senior Research Consultant with Accuvant LABS Vulnerability Discovery & Exploitation Binary/Source Audit, Reverse Engineering – Contributor Formerly Lead Exploit Developer
Motivation …share information and techniques to make Java Runtime Environment (JRE) exploitation easier. – JRE architecture information – Various hurdles encountered during exploit dev i.e. CVE , CVE – Provide tools for future work
Background Why Java? – Many reasons Wide install base – 85% of Windows boxes More claims here:
Background Java is cross-platform!
Background - Security Buggy – Well over 100 CVEs Targeted in 73% of exploit kits exploits in – 6 Windows specific – 1 meatware attack (java_signed_applet) – Only 4 involve memory corruption!?
Background - Versions JRE 6 – Used 6u29 for testing – 6u31 is latest JRE 7 – Initial release buggy… – Slow adoption… – Third update out (7u3)
Background - Recommended Reading JRE
Background Java has multiple attack vectors – Browser Plug-in Automatically installed Applets – 70% of Metasploit Java exploits use Applets “LiveConnect” Java/Browser interface – Java Web Start & JNLP – More
Background - Applets Attackers use applets because… – Applet Java code and JAR contents are 100% attacker controlled – Tons of native library code is reachable via JNI Images, Sounds, Compressors and more Includes embedded copies of open source (zlib, etc) TrustedUntrusted SignedUnsigned Runs with full user privilegesSubject to Java “sandbox” User is PromptedNo prompting
Background - Technical Java Virtual Machine (JVM) – Named “HotSpot” – Written in native code – Processes Java Bytecode – Might just-in-time compile – Executes or Interprets resulting code
Background – Security Process Architecture – Plug-in loads in Browser address space Includes several libraries – Since Update 10 Java.exe runs as an external process Can Pass options to Java.exe via HTML – Still no DEP – Still no ASLR
Background – Security All JRE 6 releases ship same msvcr71.dll – v md5 86f1895ae8c5e8b17d99ece768a70732 Loads in all components! – Browser itself – Java.exe for applets Public ROP chains target this DLL
Background - Technical Multiple types of heaps – Java Object heap (more in a sec) – Native heap (from msvcr71.dll) Just a wrapper around HeapAlloc – OS-specific allocator security properties apply » ASLR » Safe-unlinking » Meta-data validation » etc System tray
Background - Technical Java Object heap – Garbage Collected – Allocated via VirtualAlloc – Was Read/Write/Execute until update 18 !! – Predictable address Between 0x and 0x Due to “Class Data Sharing” ??
Background - Technical Class Data Sharing – For optimization – Memory mapped file C:\Program Files (x86)\Java\jre6\bin\client\classes.jsa Includes native pointers?! Enable/disable with –Xshare option – Defaults to “auto”
Hurdles - I Debugging JVM started from browser Process terminates out from under you! – Surprise! Why does this happen? Continue after a while Single step exception?! Oh no! Process DIED!
Hurdles - Watchdog Java Plugin Watchdog – Watches over external jp2launcher.exe process Java_java_lang_ProcessImpl_destroy (inside java.dll) TerminateProcess
Hurdles - Watchdog Prevent the watchdog from interfering! – C:\> set JPI_PLUGIN2_NO_HEARTBEAT=1 Thanks Nils Remi! Could also… 1.Patch up the “java.dll” binary NOP TerminateProcess call or change JNZ -> JMP 2.Use breakpoints, runtime patching, etc Must be done each execution
Hurdles – Random AVs Spurious access violations while debugging Not sure why… Let’s speculate. – Expected AV in JIT’d code? – Crap code wrapped in catch-all handler? Just pass and pretend its not happening ;-P
Hurdles - Encoding Java uses UTF-8 for all strings Invalid sequences replaced with ‘?’
Hurdles - Encoding Not just at runtime… Check this out:
Hurdles - Encoding Compile and run it… But it was all comments?! Java pre-processes those UTF escapes!
Hurdles - Encoding Arrays are better than strings – Their values are represented in memory contiguously Get usable addresses mapped with our stuff – Spray-n-pray
Hurdles – Integers In Java, all integers are signed! Use next larger type – For 0xff byte, use short integer – For 0xffff short, use long integer – etc
Hurdles - Reachability Code that seems unreachable at first – Example, CVE You can reach more by using Java tricks – Sub-classing – Reflection – Abusing complex interfaces i.e. A class that takes an instance as a parameter
Exploiting: Setup Used a custom JNI (vuln_jni.dll) for testing – Covers several common exploit primitives
Exploiting: Arbitrary Call Fun and simple.. – Just need somewhere to jump! – Good thing JRE 6 doesn’t support ASLR! Public ROPs work great – Nor does it support DEP! Let’s jump into a DLL.data section!
Exploiting: Write4 Surgical! – Need to target something used for control flow Must know it’s address (within margin of error) A plethora of stuff to surgically overwrite – Again, lack of ASLR / DEP FTW
Vuln.sprintf Here’s the code: Two issues in this function – CWE-121: Stack Buffer Overflow – CWE-134: Uncontrolled Format String
Exploiting: Format String One of my personal favorites Java’s C runtime has “%n” disabled – (Un)fortunately? May still be useful – Leak memory contents – Cause buffer overflows (%1024xAAAABBBB)
Exploiting: Stack BOF Pet peeve: NOT A STACK OVERFLOW Traditional methods can be tricky do to UTF8 issues – Just pad with stuff and control EIP – Some characters still aren’t usable CVE / CVE
Exploiting: Heap BOF Heap Buffer Overflow – Depends on what you corrupt! Native heap protections make for pain and suffering Unlikely to overflow Java Object Heap data
Exploiting: CVE setDiffICM Stack BOF – Native Method: Java_sun_awt_image_ImageRepresentation_setDiffICM Called from ImageRepresentation.setPixels sun.awt.* can’t be used in an Applet! – java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.awt.image) Using a custom ImageFilter we can!
Exploiting: CVE New Plug-in “docbase” Stack BOF – No stack cookie?! – Encoding issues come into play – Issue occurs in browser address space – Modern browsers use SetProcessDEPPolicy to force permanent DEP on – Used a custom ROP chain that predates publication of WP/Corelan chains
!! BONUS !! SOURCEZ – Java Research License (JRL) For <= 6u23-b05 – openjdk / icedtea source code – jdk.net hg repositories SYMBOLZ – Early Access program (EA)
JRE7 – Impervious? JIT Spraying – Code region is RWX! – Emitted code too inefficient – Limited size Java Object Heap address is still predictable – Between 0x and 0x
Conclusions Exploiting JRE 6 can be painful, but… It’s easier than it should be. – Well behind the mitigation curve No ASLR or DEP Predictable memory layout – Vast attack surface – Buggy
Recommendations Good: – Use 64-bit browser, plug-in, JRE – Migrate to JRE 7 – Use EMET to force ASLR and DEP
Recommendations Good: – Use 64-bit browser, plug-in, JRE – Migrate to JRE 7 – Use EMET to force ASLR and DEP Better: – Disable browser plug-in and JNLP/Web Start Chrome neuters Java by default BEST: UNINSTALL JRE !!
QUESTIONS? Contact “jduck” on IRC jdrake [circled-a] accuvant.com FOR LULZ:
Tools Provided Batch files to accomplish… – Unattended installation – Install into VMs via VMware vmrun Intentionally vulnerable JNI Demonstrative exploits – ms broke a couple :-/ Java Heap Spray scripts Any requests?