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.

13 comments:

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

    ReplyDelete
  2. 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?

    ReplyDelete
  3. 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.

    ReplyDelete
  4. 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.

    ReplyDelete
  5. @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?

    ReplyDelete
  6. @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!

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

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

    ReplyDelete
  9. @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).

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

    ReplyDelete
  11. 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!

    ReplyDelete
  12. 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?

    ReplyDelete

Post a Comment