Attack Trends

Editors: Marcus Sachs, marcus.sachs@verizon.com

David Ahmad, drma@mac.com

Malicious PDF
Documents Explained

W
hat makes a PDF file malicious? PDF PDF Vulnerabilities
The JBIG2Decode bug is a well-
designers and the PDF reader software known vulnerability in the Adobe
Reader PDF language. The PDF
architects never intended for files to be language supports the inclusion
of many types of image formats,
able to modify the operating system thus the reader must be able to
decode and decompress many for-
running the PDF reader. But security researchers and malware mats. Several bugs in the JBIG2
decoding algorithm’s implemen-
Didier Stevens authors found ways to exploit The PDF language supports tation give attackers execution
Contraste PDF readers’ software bugs and embedded JavaScript. The em- control when they embed a mal-
Europe NV to creatively use the PDF lan- bedded JavaScript interpreter is formed image into the PDF docu-
guage, enabling them to produce limited in its interaction with the ment. When users open a PDF
PDF documents that execute ar- operating system—for instance, document with a vulnerable PDF
bitrary code. the JavaScript interpreter can’t reader, the reader tries to render
Embedded files are a good read from and write to arbitrary the image by decompressing the
example of this design philoso- files on the file system. malformed image data, causing
phy. The PDF language allows JavaScript is often used for form the decompression algorithm to
files to be embedded inside PDF validation and calculation. When malfunction and giving attackers
documents. For example, you designing a PDF form, users can execution control. What happens
could use this feature to include a add extended input validation with next depends on the payload code
spreadsheet in a PDF document. JavaScript. For example, when a the attacker includes in the PDF
Although embedding executable form requires a credit-card number, document. Adobe has fixed this
files is technically possible, PDF users can add JavaScript to check JBIG2Decode bug; it can no lon-
reader software won’t let you ex- the number with the Luhn formula ger be exploited on recent versions
tract and launch embedded ex- (a checksum algorithm used for a of Adobe Reader.
ecutable files. It blacklists several variety of identification numbers). A well-known vulnerability in
types of executable files based on On PDF order forms, JavaScript the PDF JavaScript language is a
file extension, but blacklisting calculates totals and sales tax. bug in util.printf. Program-
has its limitations. For example, Attackers can create malware mers use this printf function to
Python code (extension .py) isn’t based on bugs in the PDF and format data in particular forms, for
blacklisted and can be extracted Java­Script languages’ implementa- example, converting a floating-­
and launched from a PDF docu- tion. Some bugs can be triggered point number to a string repre-
ment, provided the user accepts in such a way that they provide sentation of the floating-point
the warning dialog box. control over the execution of number with two digits after the
This is a simple example of how machine language by the micro- decimal point. The programmer
an attacker can create a PDF doc- processor (so-called extended in- provides a format string parameter
ument with a malicious payload. struction pointer [EIP] control). to instruct the printf function
However, most malware authors These bugs, called vulnerabilities, on the format to use. A bug in the
won’t use this technique because let the attacker take control over algorithm’s implementation in-
it requires some user cooperation the attacked program. Such attack terprets this format string. When
and because most Windows ma- code, or exploit, is often specially attackers call the util.printf
chines don’t have a Python inter- crafted data that causes the pro- with a particular format string and
preter installed. gram to malfunction. numerical argument, the printf

80 COPUBLISHED BY THE IEEE COMPUTER AND RELIABILITY SOCIETIES 1540-7993/11/$26.00 © 2011 IEEE JANUARY/FEBRUARY 2011
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on September 22,2022 at 18:01:58 UTC from IEEE Xplore. Restrictions apply.
 Attack Trends

function malfunctions in such a Attack Methods location, these attackers plant their
way that it provides attackers ex- Skilled attackers craft their attacks shellcode at the location the EIP is
ecution control. To exploit this to obtain complete and precise pointing to after exploitation.
vulnerability, attackers created a control over the EIP. They include Because the PDF and JavaScript
PDF document with embedded their shellcode in the PDF docu- languages don’t provide attack-
JavaScript that calls function util. ment loaded into the running PDF ers with a means to precisely plant
printf. In the PDF language, reader’s memory. This shellcode shellcode at an arbitrary address, at-
JavaScript execution is linked will thus be loaded into memory tackers developed a workaround—
to actions. In this case, attackers at a known location, which usu- heap spraying—in which shellcode
linked the JavaScript execution ally depends on the targeted Win- is stored inside a JavaScript string
to the action of opening the PDF dows operating system’s version that is copied many times (10,000
document—when the document and configuration. To execute the to 100,000 times). The result is that
opens, the JavaScript executes and shellcode, attackers must craft the the JavaScript interpreter’s memory
exploits the vulnerability. Adobe data passed to the vulnerable func- for strings and other data (called
has fixed this bug as well. tion—for example, malformed the heap) is filled with strings con-
image data for JBIG2Decode—so taining shellcode. When the EIP
Execution Control that the EIP will point to the start points to the heap (for example,
When attackers obtain execution of the shellcode. 0x30303030), there’s a good chance
control, a program’s normal flow Less-skilled attackers obtain that it’ll point to the “sprayed”
is disrupted. When a program only partial control over the EIP. shellcode (depending on how much
executes, the microprocessor ex- They can make the EIP point out- the attacker sprayed the heap).
ecutes a sequence of instructions. side of the normal set of instruc- So, less-skilled attackers will
This isn’t a linear sequence; the tions, but they can’t make it point combine an exploit with a Java­
program flow will frequently to a specific location. For example, Script heap spray to attack Adobe
jump from one set of instructions they can only make the EIP point Reader. However, there’s one ca-
to another owing to conditional to location 0x30303030. Because veat: if the EIP points somewhere
statements, subroutine calls, inter- they aren’t skilled enough or don’t in the shellcode, but not exactly at
rupts, and so forth. have the resources to make the the start of the shellcode, the shell-
When a function (a set of in- EIP point to a precise shellcode code will fail to execute properly.
structions) contains bugs, its pro-
gram flow won’t execute the way
the programmer intended. When
a buggy function’s program flow
can be forced to jump outside of
the function to a completely dif-
ferent set of instructions, the bug
qualifies as a vulnerability. This
means the attacker has obtained
control over the EIP. The instruc-
tion pointer is a critical register
in the microprocessor that points
to the microprocessor’s execution
instruction. Once the instruc-
tion executes, the EIP will point
to the next sequential instruction,
unless the executed instruction
has changed the EIP and there-
by changed the program flow.
A successful exploitation of the
function’s vulnerability will let at-
tackers change the EIP to point to
an instruction they provide. They
can then force the attacked pro-
gram to execute a set of malicious
instructions, or shellcode.

www.computer.org/security 81
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on September 22,2022 at 18:01:58 UTC from IEEE Xplore. Restrictions apply.
 Attack Trends
The heap spray programmer works
around this problem by prefixing
the shellcode with a long sequence
of single-byte instructions that es-
sentially do nothing—NOP (no
operation) instructions—in which
the EIP is incremented to pass
execution to the next NOP in-
struction. A NOP sled is a long se-
quence of NOP instructions (easily
50,000 bytes long). In a classic heap
spray, the shellcode (approximately
100 bytes) is prefixed with a long
NOP sled, and attackers repeatedly
spray this into the heap.
Because the heap is filled with
large NOP sleds and small shell-
code, the EIP will likely point
somewhere into a NOP sled, rath-
er than in the shellcode. On ex-
ecution of the NOP sled, the EIP
slides all the way up the NOP sled,
until it encounters the shellcode’s
first instruction and executes it.
Most of the PDF malware found
in the wild exploits a PDF language
or JavaScript vulnerability and uses
JavaScript heap spray to execute
shellcode. This can be partially ex-
plained by the use of fuzzing to find
bugs. PDF fuzzing is an automatic
method in which a program creates
a very large set of PDF documents
that are all different from each oth-
er by making small changes to the
PDF document’s parameters and
data structures. Each document
is automatically opened with the
PDF reader under investigation; the
hope is to find PDF documents that
are malformed in such a way that
they crash the PDF reader. If the
crash analysis reveals that the crash
was caused by the EIP pointing to
a place where there was no memory
segment, and this location is inside
the heap, then attackers can eas-
ily transform this malformed PDF
document in an exploit by adding
JavaScript to heap spray shellcode.
Depending on the heap size,
JavaScript heap spraying can take
several minutes. If after opening a
malicious PDF document the PDF
reader becomes unresponsive for
82 IEEE SECURITY & PRIVACY
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on September 22,2022 at 18:01:58 UTC from IEEE Xplore. Restrictions apply.
a long period, the JavaScript heap
spray is running. When the PDF
reader becomes responsive again,
the heap spray is complete and the
exploit has executed, or is still ex-
ecuting. The best thing to do in
that case is kill the PDF reader
process while it’s still in the heap-
spraying phase.
PDF Shellcode Types
Attackers can design shellcode to
do almost anything, but because
developing complex shellcode
requires specialized skills, most
malicious PDF shellcode can be
classified in two categories (ex-
cluding malicious PDF documents
used in targeted attacks).
The first downloads an ex-
ecutable via HTTP from a web-
site, writes it to disk, executes the
downloaded executable (creating a
new process), and terminates its ex-
ecution. This often results in a PDF
reader crash, unless the malicious
author has taken special precautions
not to crash the reader program.
The second extracts an embed-
ded executable from the PDF doc-
ument, writes it to disk, and then
executes the embedded execut-
able. The shellcode uses its own
method to extract embedded ex-
ecutables; it’s not hindered by the
restrictions the PDF reader soft-
ware imposes on embedded files.
T hese are the principles under-
lying the recommendations
to disable JavaScript in the PDF
reader to mitigate 0-day vulner-
abilities. If the vulnerability is in a
JavaScript function, then disabling
the JavaScript execution will pre-
vent it from calling and exploiting
the vulnerable function.
If the vulnerability is in the
PDF language’s implementation,
then disabling JavaScript will
mitigate the attack by prevent-
ing the JavaScript heap spray from
executing. In most cases, the PDF
reader will just crash. The exploit
will run, but because the Java­
Script heap spray didn’t execute,
there’s no shellcode in memory to
take control over the machine. Of
course, when dealing with skilled
attackers that don’t use heap sprays,
disabling JavaScript won’t mitigate
a PDF language bug’s exploitation.
PDF reader software designers
have begun using Windows se­
curity features such as data execu-
tion prevention (DEP) and address
space layout randomization (ASLR)
to prevent exploits from executing.
In the case of Adobe, only the latest
version of Adobe Reader (version 9
and X) uses such Windows security
features when it executes on recent
versions of Windows (Windows
Vista and Windows 7). DEP avoids
exploits by preventing execution of
code located in memory dedicated
to data. ASLR changes the entry
point of Windows API functions
and application functions every
time Windows boots. This way,
shellcode can’t use hard-coded
Windows API function addresses.
Although there are techniques
to bypass DEP and ASLR, they
make the attacker’s job harder.
In November 2011, Adobe re-
leased Adobe Reader X. This ver-
sion comes with a new feature
known as Protected Mode Adobe
Reader. PMAR uses a sandbox
to isolate the rendering engine of
Adobe Reader from the rest of the
operating system. Even if malware
manages to bypass DEP and ASLR,
the sandbox will prevent it from al-
tering the operating system, hence
stopping the malware infection.
Didier Stevens is an IT security
consultant at Contraste Europe NV,
an IT consulting services company. In
2011, Didier was awarded Microsoft
MVP Consumer Security. Contact
him via his IT security-related blog at
blog.DidierStevens.com.
Selected CS articles and columns
are also available for free at
http://ComputingNow.computer.org.
JANUARY/FEBRUARY 2011