Re: [VulnWatch] Adobe Acrobat/Acrobat Reader ActiveX Control Buffer Overflow Vulnerability

From: Berend-Jan Wever (
Date: 08/19/04

  • Next message: Jake: "[VulnWatch] Open Source Vulnerability Database Opens Vendor Dictionary"
    To: <>, <>
    Date: Thu, 19 Aug 2004 01:05:23 +0200

    I tested this with 6.0.1: No overflows as far as I can see, but then again I didn't test it on the mentioned webservers: I wrote a small "webserver" myself that returned a valid HTTP reply with a pdf file for ANY request (reply copy-pasted from an apache server).
    No matter what I tried, I didn't get any overflows...

    So either 6.0.1 isn't affected or I'm not doing this the right way...
    The "websever" is attached, including the reply, use like this:
    babyjee@papa:~/prg/exploits/pdf$ Necrobat && ./Necrobat [PORT] <pdf.reply

    Did anybody look into this ?


    PS. Don't give my crap about the Necrobat.c source, I slapped the thing together in under a minute so I know it's total crap.

    ----- Original Message -----
    From: "Chris Wysopal" <>
    To: <>
    Sent: Wednesday, August 18, 2004 17:00
    Subject: [VulnWatch] Adobe Acrobat/Acrobat Reader ActiveX Control Buffer Overflow Vulnerability

    > Adobe Acrobat/Acrobat Reader ActiveX Control Buffer Overflow Vulnerability
    > iDEFENSE Security Advisory 08.13.04:
    > Adobe Acrobat/Acrobat Reader are programs for creating and/or viewing
    > documents in Adobe Portable Document Format (PDF). More information is
    > available at
    > Exploitation of a buffer overflow vulnerability in the ActiveX component
    > packaged with Adobe Systems Inc.'s Acrobat/Acrobat Reader allows remote
    > attackers to execute arbitrary code.
    > The problem specifically exists upon retrieving a link of the following
    > form:
    > GET /any_existing_dir/any_existing_pdf.pdf%00[long string] HTTP/1.1
    > Where [long string] is a malicious crafted long string containing
    > acceptable URI characters. The request must be made to a web server that
    > truncates the request at the null byte (%00), otherwise an invalid file
    > name is specified and a "file not found" page will be returned. Example
    > web servers that truncate the requested URI include Microsoft IIS and
    > Netscape Enterprise. Though the requested URI is truncated for the
    > purposes of locating the file the long string is still passed to the
    > Adobe ActiveX component responsible for rendering the page. This in turn
    > triggers a buffer overflow within RTLHeapFree() allowing for an attacker
    > to overwrite an arbitrary word in memory. The responsible instructions
    > from RTLHeapFree() are shown here:
    > 0x77F83AE5 MOV EAX,[EDI+8]
    > 0x77F83AE8 MOV ECX,[EDI+C]
    > ...
    > 0x77F83AED MOV [ECX],EAX
    > The register EDI contains a pointer to a user-supplied string. The
    > attacker therefore has control over both the ECX and EAX registers used
    > in the shown MOV instruction.
    > Successful exploitation allows remote attackers to utilize the arbitrary
    > word overwrite to redirect the flow of control and eventually take
    > control of the affected system. Code execution will occur under the
    > context of the user that instantiated the vulnerable version of Adobe
    > Acrobat.
    > An attacker does not need to establish a malicious web site as
    > exploitation can occur by adding malicious content to the end of any
    > embedded link and referencing any Microsoft IIS or Netscape Enterprise
    > web server. Clicking on a direct malicious link is also not required as
    > it may be embedded within an IMAGE tag, an IFRAME or an auto-loading
    > script.
    > Successful exploitation requires that a payload be written such that
    > certain areas of the input are URI acceptable. This includes initial
    > injected instructions as well as certain overwritten addresses. This
    > increases the complexity of successful exploitation. While not trivial,
    > exploitation is definitely plausible.
    > iDEFENSE has confirmed the existence of this vulnerability in Adobe
    > Acrobat 5.0.5, specifically, pdf.ocx version It is suspected
    > that all current versions of Adobe Acrobat/Acrobat Reader are affected
    > by this vulnerability.
    > Change Adobe Acrobat/Acrobat Reader settings to prevent PDF files from
    > automatically opening when accessed via a web browser. When prompted,
    > first save the file to disk before opening thereby closing the
    > exploitation vector described.
    > This can be accomplished using the following steps:
    > 1. Open Adobe Acrobat/Acrobat Reader
    > 2. Go to Edit --> Preferences
    > 3. Uncheck the "Display PDF in browser" setting
    > 4. Click OK
    > iDEFENSE brought this vulnerability to the attention of the vendor
    > according to the publicized timeline. However, the vendor appears to
    > have attempted to silently fix this vulnerability without coordinating
    > public disclosure of the issue. Moreover, the vendor does not appear to
    > have publicly posted details of the security fix to inform clients of
    > the risks posed by unpatched versions of the software.
    > Adobe has stated that the vulnerability was patched in Adobe Acrobat
    > Reader 6.0.2. However, iDEFENSE has tested proof of concept exploit code
    > that will cause the latest version of Adobe Acrobat Reader (6.0.2) to
    > crash. Adobe has not provided details on the status of a fix for Adobe
    > Acrobat.
    > The Common Vulnerabilities and Exposures (CVE) project has assigned the
    > name CAN-2004-0629 to this issue. This is a candidate for inclusion in
    > the CVE list (, which standardizes names for
    > security problems.
    > 04/19/2004 Initial vendor notification
    > 04/19/2004 iDEFENSE clients notified
    > 04/19/2004 Initial vendor response
    > 06/07/2004 Approximate release date of Adobe Acrobat Reader 6.0.2
    > 08/13/2004 Public disclosure
    > IX. CREDIT
    > Rafel Ivgi (the_insider[at] is credited with this discovery.
    > Get paid for vulnerability research
    > Copyright 2004 iDEFENSE, Inc.
    > Permission is granted for the redistribution of this alert
    > electronically. It may not be edited in any way without the express
    > written consent of iDEFENSE. If you wish to reprint the whole or any
    > part of this alert in any other medium other than electronically, please
    > email for permission.
    > Disclaimer: The information in the advisory is believed to be accurate
    > at the time of publishing based on currently available information. Use
    > of the information constitutes acceptance for use in an AS IS condition.
    > There are no warranties with regard to this information. Neither the
    > author nor the publisher accepts any liability for any direct, indirect,
    > or consequential loss or damage arising from use of, or reliance on,
    > this information.


  • Next message: Jake: "[VulnWatch] Open Source Vulnerability Database Opens Vendor Dictionary"

    Relevant Pages