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... http://server:port/whatever.pdf%00AAAAAAAAAAAAAAAAAAAAAAAAAAA... http://server:port/whatever.pdf?AAAAAAAAAAAAAAAAAAAAAAAAAAAAA... http://server:port/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... http://server:port/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...AAAAAAAA.pdf 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 ? Cheers, SkyLined 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" <weld@xxxxxxxxxxxxx> To: <vulnwatch@xxxxxxxxxxxxx> 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: > > I. BACKGROUND > > Adobe Acrobat/Acrobat Reader are programs for creating and/or viewing > documents in Adobe Portable Document Format (PDF). More information is > available at http://www.adobe.com/products/acrobat/. > > II. DESCRIPTION > > 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. > > III. ANALYSIS > > 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. > > IV. DETECTION > > iDEFENSE has confirmed the existence of this vulnerability in Adobe > Acrobat 5.0.5, specifically, pdf.ocx version 5.0.5.452. It is suspected > that all current versions of Adobe Acrobat/Acrobat Reader are affected > by this vulnerability. > > V. WORKAROUND > > 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 > > VI. VENDOR RESPONSE > > 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. > > VII. CVE INFORMATION > > 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 (http://cve.mitre.org), which standardizes names for > security problems. > > VIII. DISCLOSURE TIMELINE > > 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]mail.com) is credited with this discovery. > > Get paid for vulnerability research > http://www.idefense.com/poi/teams/vcp.jsp > > X. LEGAL NOTICES > > 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 customerservice@xxxxxxxxxxxx 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.
Attachment:
Necrobat.c
Description: Binary data
Attachment:
pdf.reply
Description: Binary data