My Java SIGSEGV's

During couple of last days I was checking lcamtuf’s American Fuzzy Lop against some (“non-instrumented”) binaries. 

I was wondering, what will happen if I will run it against Java… ;)

I was looking for some sources, but unfortunately I wasn’t able to find any. Next thing was checking where I have Java installed (so I will know what/where I can check. Kind of ‘test lab’ was: Ubuntu 12, Kali Linux, WinXP, Win7. (Exact version of Java installed on that OS’s you will find below.)

After 2 days there were approx. 170 different samples. After first check, we can see that java (7) will 

end up with sigsegv (with SSP enabled – Kali Linux):

Same sample with Java 6 will produce:

Next thing I saw was:

*** buffer overflow detected ***: /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java terminated

During the analysis of the crash file in gdb I found some “new” function names. I decide to find them also but in Ida Pro and check, what is their purpose:

 

(As you can see, some core files were generated by valgrind.)

Below “find_file” function (from IdaPro):

You can easily see that we have malloc() here.

Next thing I decide to check was JLI_ParseManifest() function:

 

 

After checking those functions, we can see that JLI_ParseManifest() will iterate through each character in Manifest file. Correct me if I’m wrong but I think that find_file() is the place when SIGSEGV occurs. Manifest file is parsed here:

When we will set up “Windbg” (in IdaPro) to run Java with our sample.jar file (generated by afl), we will see, that crash occurs in similar region:

After this warning, Ida will jump to next location:

 

In text mode view, we can see more instructions:

 

Let’s see if in pseudocode (Tab/F5) we will find any hint:

 

We see the memcpy() function  with 3 arguments: v4, v3 and v5. Details about those variables we can find in the beginning of the pseudocode:

 

Now we know that v3 is the value from esi, v4 is the value from edi and v5 is the value from ecx. Next thing is generating and saving dump file. We will open it in Windbg later:

 

Now, open java.dmp file in Windbg and observe results:

 

We can see that SIGSEGV occurs when the program is using EDI and ESI registers. Let’s check what’s on that location: let’s use the “dc” command:

 

In case that you will ask what !exploitable will tell you about it, screen below:

 

Short summary: this sample file will crash Java on all mentioned systems.

If you think that this is exploitable… Well. Let me know what do you think about (comments or emails). Any ideas are welcome. ;)