1 / 50

Exploiting Memory Corruption Vulnerabilities in Java Runtime

This presentation by Joshua J. Drake explores techniques for exploiting memory corruption vulnerabilities in the Java Runtime Environment (JRE), including information on JRE architecture, hurdles encountered during exploit development, and tools for future work.

lanaa
Download Presentation

Exploiting Memory Corruption Vulnerabilities in Java Runtime

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Exploiting Memory Corruption Vulnerabilities in the Java Runtime Joshua J. DrakeInaugural InfoSec SouthwestMarch 31st 2012

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

  3. Overview Background Hurdles Exploiting Demos Conclusion

  4. 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-2009-3867, CVE-2009-3869 • Provide tools for future work

  5. Background • Why Java? • Many reasons • Wide install base • 85% of Windows boxes More claims here: http://www.java.com/en/about/

  6. Background Java is cross-platform!

  7. Background - Security • Buggy • Well over 100 CVEs • Targeted in 73% of exploit kits • 10 15 exploits in • 6 Windows specific • 1 meatware attack (java_signed_applet) • Only 4 involve memory corruption!?

  8. Background - Versions • JRE 6 • Used 6u29for testing • 6u31 is latest • JRE 7 • Initial release buggy… • Slow adoption… • Third update out(7u3)

  9. Background JRE http://java.sun.com/products/hotspot/whitepaper.html- Recommended Reading

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

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

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

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

  14. Background – Security • All JRE 6 releases ship same msvcr71.dll • v7.10.3052.4 • md5 86f1895ae8c5e8b17d99ece768a70732 • Loads in all components! • Browser itself • Java.exe for applets • Public ROP chains target this DLL

  15. 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 

  16. Background - Technical • Java Object heap • Garbage Collected • Allocated via VirtualAlloc • Was Read/Write/Executeuntil update 18 !! • Predictable address • Between 0x22000000 and 0x26000000 • Due to “Class Data Sharing” ??

  17. 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”

  18. Hurdles

  19. 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!

  20. Hurdles - Watchdog • Java Plugin Watchdog • Watches over external jp2launcher.exe process Java_java_lang_ProcessImpl_destroy (inside java.dll) TerminateProcess

  21. Hurdles - Watchdog • Prevent the watchdog from interfering! • C:\> set JPI_PLUGIN2_NO_HEARTBEAT=1 • Thanks Nils Remi! • Could also… • Patch up the “java.dll” binary • NOP TerminateProcess call or change JNZ -> JMP • Use breakpoints, runtime patching, etc • Must be done each execution 

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

  23. Hurdles - Encoding Java uses UTF-8 for all strings Invalid sequences replaced with ‘?’

  24. Hurdles - Encoding Not just at runtime… Check this out: (from @mihi42)

  25. Hurdles - Encoding • Compile and run it… • But it was all comments?! • Java pre-processes those UTF escapes!

  26. Hurdles - Encoding • Arrays are better than strings • Their values are represented in memory contiguously • Get usable addresses mapped with our stuff • Spray-n-pray

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

  28. Hurdles - Reachability • Code that seems unreachable at first • Example, CVE-2009-3869 • 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

  29. Exploiting(yay)

  30. Exploiting: Setup • Used a custom JNI (vuln_jni.dll) for testing • Covers several common exploit primitives

  31. 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!

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

  33. Vuln.sprintf • Here’s the code: • Two issues in this function • CWE-121: Stack Buffer Overflow • CWE-134: Uncontrolled Format String

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

  35. 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-2009-3867 / CVE-2009-3869

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

  37. Exploiting: CVE-2009-3869 • 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.RuntimePermissionaccessClassInPackage.sun.awt.image) • Using a custom ImageFilter we can!

  38. Exploiting: CVE-2010-3552 • 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

  39. Exploit Demos!

  40. !! BONUS !! • SOURCEZ • Java Research License (JRL) • For <= 6u23-b05 • openjdk / icedtea source code • jdk.net hg repositories • SYMBOLZ • Early Access program (EA)

  41. JRE7 – Impervious? • JIT Spraying • Code region is RWX! • Emitted code too inefficient • Limited size • Java Object Heap address is still predictable • Between 0x22000000 and 0x26000000

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

  43. Recommendations • Good: • Use 64-bit browser, plug-in, JRE • Migrate to JRE 7 • Use EMET to force ASLR and DEP

  44. 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 !!

  45. QUESTIONS? Contact information: @jduck1337 “jduck” on IRC Email: jdrake [circled-a] accuvant.com • FOR LULZ: http://harmful.cat-v.org/software/java

  46. Tools Provided • Batch files to accomplish… • Unattended installation • Install into VMs via VMware vmrun • Intentionally vulnerable JNI • Demonstrative exploits • ms12-001 broke a couple :-/ • Java Heap Spray scripts • Any requests?

  47. References • Slide 3 • http://kelseywinterkorn.com/ • Slide 6 • http://www.oracle.com/technetwork/java/javase/system-configurations-135212.html • Slide 7 • http://www.isecpartners.com/storage/docs/presentations/EIP-final.pdf • Slide 8 • http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html • http://adtmag.com/articles/2011/08/01/java-7-crashing.aspx • http://www.oracle.com/technetwork/java/archive-139210.html • Slide 9 • http://java.sun.com/products/hotspot/whitepaper.html • Slide 12 • http://download.oracle.com/docs/cd/E19455-01/806-3461/ch1intro-3/index.html • Slide 16 • http://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf • Slide 17 • http://download.oracle.com/javase/6/docs/technotes/guides/vm/class-data-sharing.html • Slide 21 • https://twitter.com/#!/nilsremi/status/150128742973448192 • Slide ? • http://www.oracle.com/technetwork/java/javase/index-135519.html • http://www.oracle.com/technetwork/java/javase/jre-install-137694.html • http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html

  48. Change Summary • Update 10 • New browser plug-in • Always installed (no custom install options) • Runs an external java.exe process • Allows controlling heap size • Allows selecting JRE version • Patch-in-place or Static • Update 18 • Java Heap no longer RWX! • Auto-updater a separatepackage (can remove) • Prompt changes?

  49. Exploiting: CVE-2009-3867 • getSoundbank file:// URI Stack BOF • Affects JRE <= 6u16, 5u21, 1.4.2_24, 1.3.1_26 • KF’s PoC showed cross-platform PC control • version • Passes “np” & “sc” applet PARAMs • Nops and Shellcode – allows cross-platform targeting • Sprays the Java Object Heap • Overwrites saved PC (no SEH) • Jumps to Java Object Heap (was still RWX)

More Related