Didier Stevens

Wednesday 28 May 2008

I Still Use Foxit Reader

Filed under: PDF,Vulnerabilities — Didier Stevens @ 8:38

Foxit Reader has been my default PDF reader for more than a year now, as an alternative to the Adobe Acrobat Reader that stalled too often when starting up.

While playing with the PDF file format, I created several PDF files that uncovered potential security issues with Foxit Reader.

A PDF file with an OpenAction triggering an URI action causes Adobe Acrobat to prompt the user for approval, before accessing the URI:

But Foxit Reader opens Internet Explorer and visits the site without confirmation prompt. I submitted a feature request to Foxit Software for this.

Another example is a JavaScript inside a PDF file that switches the reader to full screen mode. Adobe Acrobat Reader will warn you for spoofing attacks and ask for your permission to switch to full screen, while Foxit Reader does this immediately.

Of course, these warnings will only help a user that is aware of the potential risks. But in a corporate environment, you can also set the appropriate registry keys to block all these actions by default.

It was also trivial to assemble some simple malformed PDF files that cause problems for Foxit Reader, but not for Adobe Reader. I submitted these files to Foxit Software.

Adobe Acrobat Reader allows you to disable JavaScript. Until recently, Foxit Reader required a JavaScript plugin for JavaScript support. Omitting the plugin was a simple way to disable JavaScript. But since version 2.2, JavaScript is embedded in the main executable and there is no configuration switch to disable it. Many Foxit Reader users have requested this feature.

If you absolutely want to disable JavaScript in Foxit Reader 2.3, there’s a quick and dirty trick. Search for the ASCII string JavaScript (preceded and terminated by byte 00) in the Foxit Reader executable (you should find only one occurrence), and replace it with javascript, for example. Actually, this patch will not disable the JavaScript interpreter for Foxit Reader, but it will prevent Foxit Reader from recognizing the /JavaScript name in a PDF document, effectively making it to ignore JavaScript instructions (names are case-sensitive).

You can make this patch permanently by editing the Foxit Reader executable with an hex editor, or do it temporarily by patching in memory with my bpmtk utility. The command to achieve this is:

search-and-write module:. hex:004A61766153637269707400 hex:006A

Of course, this is not a serious risk analysis of Foxit Reader. I started to use Foxit Reader as a solution to the Adobe Acrobat Reader performance problems, not for security reasons. And now that I’ve delved into the PDF file format, I did some random tests with Foxit Reader and Adobe Acrobat Reader. This gave me the impression that Adobe has more experience with security risks and vulnerabilities, than Foxit Software, and that this experience is reflected in the design of their products.

I’ll still be using Foxit Reader as my main PDF reader, and I’ll still analyze suspect PDF files in a controlled environment.

Monday 26 May 2008

Quickpost: Restricted Tokens and UAC

Filed under: Quickpost,Windows Vista — Didier Stevens @ 19:46

It seems I’m reading this question more and more: “I’m an Administrator on a Windows Vista box, but I can’t run program X with administrator rights”.

I’ll try to explain this quickly and simply, omitting a lot of details (if there is enough interest, I’ll make a follow-up post).

The cause of this program’s behavior is simple: restricted tokens. A token is a Windows kernel object that represents a user with all his privileges and group-memberships. The token is created when a user is login on, and is associated with all programs started by that user (i.e. processes). The Windows kernel uses the token to decide if the process is granted access to the securable objects it tries to access.

A restricted token is a special token: it’s a token that represents only a part of what a user is allowed to do. Some privileges and permissions have been removed or denied (restricted). Restricted tokens exists since Windows 2000, but as a user, you weren’t really confronted with them until Windows Vista. Since Windows Vista, restricted tokens are used to run most user programs, in stead of the normal (unrestricted) tokens. In Windows Vista, when an administrator is login on, 2 tokens are created: the normal token (with all administrative rights) and a restricted token. For security reasons, most programs are started with the restricted token. And that’s why some programs don’t run as you expect, because they need more privileges and permissions than the restricted token is giving them.

UAC decides if a program is started with the unrestricted token or the restricted token. There are several rules that guide UAC in its decision process between the 2 tokens, the application manifest is one source of information used by the UAC rules. The manifest is an XML file stored as a resource inside a PE file, and it can contain information about the execution level it needs to run correctly. If an application needs administrative rights, the developer should add an requireAdministrator value to the manifest file, so that the UAC uses the unrestricted token. If your application is missing this manifest, chances are that UAC will make the wrong decision and run the program with the wrong token.

As a user, you can also instruct UAC to use the unrestricted token: right-click the program you want to start and select “Run as administrator”.

If you often need to run the same program with administrative rights and UAC systematically makes the wrong decision about the token to use, create a shortcut to the program and check the “Run as administrator” toggle in the advanced tab:

Another way to achieve this is to add (or update) a manifest to the executable file with a resource editor.

Quickpost info

Tuesday 20 May 2008

Quickpost: eicar.pdf

Filed under: PDF,Quickpost — Didier Stevens @ 8:54

I like to embed the EICAR Anti-Virus test file in usual formats and less usual formats. Today, I’m publishing a PDF document with an embedded EICAR test file (eicar.txt). This PDF document has also an annotation with a JavaScript action linked to it. Clicking the annotation will export the embedded eicar.txt file to a temporary folder and launch the default editor for .txt files. This doesn’t work with Foxit Reader, because Foxit doesn’t support the JavaScript method I’m using to export eicar.txt (exportDataObject). But you can still export the file manually if you use Foxit Reader.

eicar.pdf contains only ASCII characters, so you can use Notepad to see what I did. And I had do to something special, can you guess what? Post your comments!

Quickpost info

Monday 19 May 2008

PDF Stream Objects

Filed under: Malware,PDF — Didier Stevens @ 6:09

A PDF stream object is a sequence of bytes. There is a virtually unlimited number of ways to represent the same byte sequence. After Names and Strings obfuscation, let’s take a look at streams.

A PDF stream object is composed of a dictionary (<< >>), the keyword stream, a sequence of bytes and the keyword endstream. All streams must be indirect objects. Here is an example:

This stream is indirect object 5 version 0. The stream dictionary must have a /Length entry, to document the length of the (encoded) byte sequence. The stream and endstream keywords are terminated with the EOL character(s). In this example, the byte sequence is a set of instructions for the PDF reader to render the string Hello World with a given font at a precise position. It’s precisely 42 bytes long.

In this example, the byte sequence is represented literally, but it’s possible (and usual) to encode the byte sequence. This is done with a stream filter. A stream filter specifies how the sequence of bytes has to be decoded. Let’s take the same example, but with an ASCII85 encoding:

The /Filter entry instructs the PDF reader how to decode the byte sequence (/ASCII85Decode). Notice the change of the length value. There are many encoding schemes (ASCII filters and decompression filters), here is a list:

  • ASCIIHexDecode
  • ASCII85Decode
  • LZWDecode
  • FlateDecode
  • RunLengthDecode
  • CCITTFaxDecode
  • JBIG2Decode
  • DCTDecode
  • JPXDecode
  • Crypt

This list is not so long, so why do I claim an almost limitless number of ways to encode a stream? I have 2 reasons:

  1. Many filters, like /FlateDecode, take parameters (in this case, the compression level), which influence the encoding too
  2. Filters can be cascaded, meaning that the stream has to be decoded by more than one filter

Here is our example, where the stream is encoded twice, first with ASCII85 and then with plain HEX (I know, this is rather pointless, but it yields simple and readable examples):

Cascading filters also inspired me to create a couple of test PDF documents. For example, I’ve created a 2642 bytes small PDF document that contains a 1GB large stream (a ZIP bomb of sorts). Some PDF readers will choke on this document.

Wednesday 7 May 2008

Solving a Little PDF Puzzle

Filed under: Forensics,Malware,PDF — Didier Stevens @ 8:22

I’m quite pleased with the feedback I received for my Little PDF Puzzle, thanks all.

As promised, I’m posting the solution now, but first be sure you understand the basic structure of a PDF file.

The PDF file format supports Incremental Updates, this means that changes to an existing PDF document can be appended to the end of the file, leaving the original content intact. When the PDF file is rendered by a PDF reader, it will display the latest version, not the original content. Remember that the basic structure of a PDF file (one without incremental updates) consists of 4 parts:

  • header
  • objects
  • cross reference table
  • trailer

A PDF file with one incremental update has the following structure:

  • header
  • objects (original content)
  • cross reference table (original content)
  • trailer (original content)
  • objects (updated content)
  • cross reference table (updated content)
  • trailer (updated content)

Every object that has been modified can be found twice in the PDF file. The unmodified object is still present in the original content, and the edited version of the same object can be found in the updated content.

The cross reference table of the updated content indexes the updated objects, and the trailer of the updated content points to both cross reference tables.

When a PDF reader renders a PDF document, it starts from the end of the file. It reads the last trailer and follows the links to the root object and the cross reference tables to build the logical structure of the document it is about to render. When the reader encounters updated objects, it ignores the original versions of the same objects.

Let’s open our PDF Puzzle with a PDF reader:

And let’s also open it with Notepad:

With Notepad, it becomes clear that I’ve created a PDF document with an incremental update (original document in red, update in blue). If you delete the updated content (the blue part, or everything after the first occurrence of %%EOF), you’ve actually recovered the original version. Save it and open it with your PDF reader:

In the original PDF document, I stored the sentence “The passphrase is Incremental Updates” in indirect object 5 (to make the puzzle a bit more challenging, I used an ASCII85 encoded stream, otherwise you could just read the solution with Notepad). Next, I updated the sentence to “The passphrase is XXXXXXXXXXXXXXXXXXX” by creating a new version of object 5 and appending this at the end of the original PDF document. To finalize the updated document, I added a new cross reference table (just indexing the new version of object 5) and a new trailer (referencing the new and the old cross reference tables).

If you produce PDF documents with a PDF editor that supports incremental updates, be aware that previous versions of your document could be included in the final document, and that this could lead to information disclosure. Most office applications that support export to PDF do not use incremental updates (because they save the document in their own native format, not PDF).

If you conduct forensic investigations or do malware research, don’t limit your analysis to the final version of a PDF document. You can easily identify incrementally updated PDF documents by looking for multiple instances of cross reference tables and trailers. But don’t get confused by Linearized PDF documents, they too have more than one cross reference table and trailer (linearized PDF documents start with an indirect object sporting a /Linearized name).

You can find interesting information in the different versions included in an incremental PDF file. For example, I have a malicious PDF sample that has been created in February 2008, updated in March 2008 to add the malicious payload (it took the author about 20 minutes) and, not surprising, that this was done on a machine with the timezone set to GMT+08.

A final detail: to allow you to edit the PDF puzzle with Notepad, I produced an ASCII-only PDF file (that’s one of the reasons I used ASCII85 encoding for the stream of indirect object 5). But most PDF documents contain non-ASCII characters, so be sure to use an editor that will support this (and that won’t convert 0x0A or 0x0D to 0x0D0A).

Tuesday 6 May 2008

A Little PDF Puzzle

Filed under: Forensics,PDF — Didier Stevens @ 8:24

I have a little PDF puzzle this week. Find the passphrase in this PDF document and post a comment with your solution. There’s a very simple solution just requiring Notepad (and your favorite PDF reader).

Blog at WordPress.com.