**ALTERNATIVE JVM EXPLOIT - EXPLOITING JVM ON CHROME- A STROY**
**RESEARCH TEAM: LEGION OF XTREMERS**
**SPECIAL GREETS TO: SECFENCE TEAM AND HACKERS GARAGE**
Note: This short paper is intended for wannabies who want to get a glance of the process/way an exploit is developed when a new vulnerability is released. I've chosen this vulnerability for the sake of simplicity and is easier to understand distinctly every step.
Here i am presenting technical details about the Alternate JVM vulnerability and its exploit development for all web browsers in the market. This story times around April 2010.
In the afternoon (10-13-2010) everyone was busy in the team about the vulnerability published in www.reversemode.com about the Java runtime environment by Tavis Ormandy. So I decided to take a look and downloaded immediately all the JRE versions available till date from JAVA's site.
Note: By that time the latest update of JRE was 6u19, which was also vulnerable and java was not considering this vulnerability as critical for windows systems. The criticality was that, every windows till date with java installed was vulnerable to remote code execution.
The activeX controls 8AD9C840-044E-11D1-B3E9-00805F499D93 and DeploymentToolkit activeX control CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA were vulnerable. The vulnerability was that an attacker can force JRe to load a DLL from a remote smb share as an alternate jvm with specific name.
Started testing but all failed. A dll was prepared and was placed in a shared folder and a webpage In first ActiveX mentioned above two parameters 'launchjnlp' and 'docbase' were vulnerable to undocumented argument passing. And one of those drastic undocumented argument was -J along with -XXaltjvm option this will lead to my rogue DLL injection.
The attacking code looked like this:
JVM Testing
But the attack failed and did not worked as intended. So I opened console and gave command:
java /?
To check its arguments. I tried some other arguments too and accidently i placed one of the
option right before "-J-XXaltjvm" and then tried. It threw an error that
Can not find \\ipaddress\share\jvm.dll\jvm.dll\jvm.dll
So accidently i now knew the two things:
1. "-J-XXaltjvm" needs some junk to be frefixed first like:
"abc -J-XXaltjvm"
2. It will automatically search for jvm.dll in specified shared folder, so no need to specify jvm.dll
Then I modified the above jvmtest.htm as:
Suppose u've placed jvm.dll file in \\ipaddress\share_folder folder then:
JVM Testing
Bingo. The dll was fired. Got my code working, but wait. Above code was not working with all jre versions. It means i need to develop something that should work with most of web browsers in the market. Above code worked with jre versions nearly 6u18 and 6u19.
The second activeX provided above had a method named launch(parameter). The parameter to the launch function was the place for our argument injection. So i altered the jvmtest.dll
JVM Testing
Now the code worked with nearly all(most) the JRE versions.But three-four days after Kaspersky researchers said that the google chrome web browser
was not vulnerable to such attacks.So it now seemed like a challenge for all the security community.I too set for tackling it and discovered that if JRE versions 6u18 and 6u19can be even targetted by applet tags without specifying the first activeX classid listed above.
But initially chrome seemed to be immune to this trick too.Soon i realised that chrome needs
src=""
And google chrome too fell in my hands....ah Kaspersky researchers, so many days of research, so huge teams, and so many best equipments, How(why) did chrome escape....???
Following code was developed to kill all browsers in the market supporting java with
latest version at that time (jre 6u19) :
JVM Testing
"Legion Of Xtremers: Security, Penetration, Virology"