Friday, February 20, 2009

Have a nice weekend! (PDF love)

Maybe you read Michael Howard's twitter feed. If so, you may be wondering why you were asked to turn off Javascript in Adobe Acrobat Reader. Well, I'm here to tell you that if you were to load a PDF file with an embedded JBIG2 image stream:

<< /Type /XObject /Subtype /Image /Width 2550 /Height 3305 /BitsPerComponent 1
/ColorSpace /DeviceGray /Filter /JBIG2Decode/DecodeParms << /jbig2Globals 13 0 R >> /Length 10 0 R /Name /X >>

stream

And the 5th byte into the stream (which is the segment header flag byte) were to have the 6th bit set indicating a large page association size:

00 00 00 01 40 00 00 33 33 33

Then the bytes shown as 00 33 33 33 above would be loaded by the following assembly in AcroRd32.dll (ecx+0x1c points to our four bytes):

5d42d889 8b411c          mov     eax,dword ptr [ecx+1Ch]
5d42d88c 85c0 test eax,eax
5d42d88e 0f84ac020000 je AcroRd32_5cd80000!PDFLTerm+0x235ad0 (5d42db40)
5d42d894 8b4e10 mov ecx,dword ptr [esi+10h]
5d42d897 8d0480 lea eax,[eax+eax*4]
5d42d89a 834481ec01 add dword ptr [ecx+eax*4-14h],1 ds:0023:07d96648=????????

eax=00ffffff
ecx=03d96660

Playing with much smaller (0x9000) or much larger would result in crashes in different areas, but in general you would control within multiples of four where you write. If you were to add to this a quick heap spray with some javascript, I don't doubt that you could write a rather reliable exploit across multiple versions of Acrobat Reader for XP, and if one were really inclined (or bored), for linux or OS X also! Yes, it crashes on all three, in versions 8 and 9. So to all of you security pros who were looking forward to a nice quiet weekend, I can't fix it, but hopefully this will make the fire drill a little less long and arduous. Have a good one!

Oh, by the way, I forgot to mention. If you happen to open an explorer window, or a browser window, or anything at all that even has the ICON of the pdf file, you're owned.

Open Source Snort rules and SEU 203 will be up in a few with coverage. The clam sigs are called Exploit.PDF-26, Exploit.PDF-27, and Exploit.PDF-28

P.S. To adobe: Matt Olney would like to know why javascript is on by default. Thanks.
Add to Technorati Favorites Digg! This

13 comments:

Matt Richard said...

This is just wrong. Did anyone notice there is no patch available and this gives enough detail for others to exploit?

jay said...

On the other hand, the exploit is already out there and this gives us enough details to defend our networks. That's the whole point of snort is it not? Wouldn't publishing the signatures give enough information on the exploit as well?

JoepGommers said...

Thanks guys, great stuff!

Chris Replogle said...

I thought we were beyond the point of arguing about making exploits public. Would you prefer that only some of the exploit sites, like milw0rm, which has several versions listed already, and packet storm were the only ones to release this info? The days of ignorance are long gone.

Matt Richard said...

Unfortunately the ignorance regarding the context of how these exploits were being used is causing people to think this disclosure is a good thing. If this exploit were being used against large numbers of users with no protection than publishing would be a good idea. In this instance the attackers learned more than the good guys.

Anyone that needed to know how this exploit worked, or obtain a sample for defensive purposes, had one. The public disclosure of this vulnerability represents a misuse of information that was supplied by customers or partners in an ignorant attempt to protect users that were at no risk to begin with. There are lots of 0days that aren't disclosed because the people who possess them have a very narrow audience and they pose little danger to the average business or individual.

This incident highlights the need for more secrecy and not less. When the "good guys" provide details like this they increase the risk to the average user while providing very little additional protection. Both signatures (IDS + AV) released by Sourcefire provide only minimal protection when used properly and no protection to most users.

Seeing the IDS signature would not provide an attacker with access to the exploit. In reality it takes time to turn information from an IDS signature into a working exploit. This time also allows the vendor to patch and protect users.

@Chris Replogle - there would be no exploit sites hosting this code if it were not for Sourcefire. This exploit was not widely used or known in the underground.

Kaph said...

@Matt How is this wrong? It is pretty solid and informative research. I take it you are not one for disclosure and would prefer the bad guys to hold all of the cards?

Mojtaba said...

@Matt

You can close this window and go to visit other sites, you can go to download security updates for your AV, it's security research blog, we visit this page to see what others did with exploit and what others understood, we do research ourself, POC and exploit available in SecurityFocus.com

So for tiny brains like you, it's so hard to understand this information is good and you should not worry about anything, just uncheck and disable Javascript of your acrobat and stay secure.... Don't afraid of such things, althought I don't think anyone would think sending you an exploit file to pwn your pc, because your pc is useless, just you have games installed, nothing useful exists in your computer at all... So relax! LOL!

Matt Richard said...

@Mojtaba LOL, that's good. Where do I find the Adobe icon? I can't seem to find it....

Tony V. said...

Very Nice Find. It Is Questionable Why Adobe Has Javascript on by default.

Matthew Watchinski said...

@Matt

Thank you for your comment and I respect your position, however I
have an ideological difference of opinion.

Since exploits for this vulnerability are already in the wild, then it
is clear that all the nefarious people already have this information.
Since the "bad-guys" have all this information already, the good-guys
should have it too. This allows the good guys to make accurate
decisions about how best to protect their networks and the assets on
them.

Reference:
"Shadowserver reported exploitation of this issue on 2009-02-19
(http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219)
and it seems that this may have been actively exploited since January
and possibly as early as December of 2008
(http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090221).

After re-scanning the zoo after the publishing of Exploit.DF-26,27,28
for ClamAv, the VRT located numerous samples dating as far back as
January 2009."

Without accurate information the good guys lose the battle to protect
their networks, as they don't know as much as the bad guys do.
Additionally, only publishing partial information gives people a false
sense of security and allows them to draw invalid conclusions. In the
case of this particular vulnerability, the false assumption is that
disabling Javascript prevents this vulnerability. This is a half
truth, disabling Javascript merely prevents its use as a mechanism to spray
the heap. Javascript has nothing to do with actual exploitation of the
vulnerability. If an unknown method exists for manipulating the heap
that doesn't involve Javascript, then this vulnerability can be exploited
whether or not you have Javascript enabled. Since this vulnerability has been
in the wild for well over a month, it is completely possible that the
bad guys have this information and the good guys don't. This means that everyone following
the advice of disable Javascript now have a completely false sense of security.

Without giving people the opportunity to make decisions for
themselves, by withholding information that the enemy already has, we
would be doing a disservice to all the good guys in the trenches
trying to protect their networks.

Additionally:

In regards to your comments equating the details published by the VRT
with public exploits, I'm going to have to disagree. The argument you make relies
on the assumption that the bad-guys are incapable of quickly locating
vulnerabilities based on limited details. Just knowing an application
has a problem anywhere is enough for any researcher to locate
potential vulnerabilities and easily narrow their search. I would
argue that without any additional information from us you would still have
exploits on milw0rm, as the public information on this vulnerability
allows for quickly locating the specific problem.

I would also disagree that reversing any type of detection is
difficult, see Errata CEO Robert Graham and CTO David Maynor BlackHat
talk on reversing ZDI / TippingPoint signatures and turning them
directly into exploits. (http://www.darkreading.com/security/management/showArticle.jhtml?articleID=208804656).

Jeremy said...

Maybe someday people will start blaming the source instead of the destination for their problems.

Mojtaba said...

According to SECUNIA:
http://secunia.com/blog/44/

Disabling Javascript solves only script kiddies made PDF files, experts can create an exploit which doesn't need JavaScript. So disabling javascript solves nothing!

Joe said...

I've run the POC examples at Milw0rm against win-98 / Acrobat 6 and saw no problems (acrobat did not crash). Can anyone else confirm that win-98 and/or acrobat 6 is (or is not) vulnerable to this exploit?