Joshua J. Drake Inaugural InfoSec Southwest March 31 st 2012

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

49. 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?

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