Adobe Acrobat and PDF security: no improvements for 2 years.
Software released in 2003 contains vulnerabilities disclosured in 2001
July 8, 2003
In early 2001, we have discovered a serious security flaw in Adobe
Acrobat and Adobe Acrobat Reader. In July'2001, we've briefly
described it in "eBook Security: Theory and Practice" speech on DefCon
security conference. Since there was no reaction from Adobe (though
Adobe representative has attended the conference), we have reported
this vulnerability to CERT in September'2002 (after more than a year),
still not disclosing technical details to the public. Only in
March'2003, CERT Vulnerability Note (VU#549913) has been published,
and after a week, Adobe has responded officially (for the first time)
issuing the Vendor Statement (JSHA-5EZQGZ), promising to fix the
problem in new versions of Adobe Acrobat and Adobe Reader software
expected in the second quarter of 2003. When these versions became
available, we have found that though some minor improvements have been
made, the whole Adobe security model is still very vulnerable, and so
sent a follow-up to both CERT and Adobe. Both parties failed to
respond. Below is the full story.
Name : ElcomSoft Co.Ltd.
E-mail : firstname.lastname@example.org
Web : http://www.elcomsoft.com
Phone / fax : +1 866 448-2703
Adobe Systems Inc is referred as "Vendor"
ElcomSoft Co.Ltd. is referred as "Reporter"
07/16/2001: "eBook Security: Theory and Practice" presentation on
06/13/2002: Report sent to vendor
09/10/2002: Report sent to CERT
10/08/2002: More detailed acknowledgment sent to reporter
10/08/2002: Initial attempt to contact vendor via web feedback
10/18/2002: Follow up to PR contact(s); point of contact initiated
10/21/2002: Authentication loop closed; technical details sent
10/29/2002: Ack asked for and received; further details sent
related to report
11/21/2002: Reporter asks for status update
11/26/2002: Ping from reporter
11/26/2002: Follow up with vendor to get status of report
11/27/2002: Ack from vendor PR contact asserting more info soon
11/28/2002: Follow up to vendor again asking for confirmation of
let the vendor know reporter is willing to wait if
details and solution acknowledged
12/02/2002: Conversation with vendor contact verifying details of
issue; mention made of issue being resolved in next
12/04/2002: Initial date identified for potential publication of the
12/09/2002: Vendor replies that their response is undergoing legal
12/18/2002: Reporter asks for status update; notes 45-day disclosure
12/18/2002: Ack reporter
12/18/2002: Ping vendor for written response again
01/05/2003: Reporter asks for status update
01/14/2003: Ack reporter; tentatively set publication date for 01/20
01/20/2003: Reporter ack
01/21/2003: Private CERT Vulnerability Card published with draft
03/19/2003: CERT Vulnerability Note (VU#549913) published:
03/25/2003: Vendor Statement (JSHA-5EZQGZ) published:
07/02/2003: Updated vulnerability report by reporter to CERT
07/04/2003: Updated vulnerability report sent by reporter to vendor
Description of the vulnerability
Adobe Acrobat Reader supports plug-ins, i.e. additional modules that
extend the functionality of Adobe Acrobat and Adobe Acrobat Reader;
plug-ins SDK and plug-ins certification (signing) mechanism are
provided. By design, Adobe Acrobat (and Reader) should load only
digitally signed plug-ins, while the key (for signing) is provided
by Adobe itself -- to developers who has signed a special agreement
with Adobe. Besides, some plug-ins are signed by Adobe using their
own private Key, and there is a 'certified' (so-called 'trusted')
mode in Acrobat, when only Adobe-certified plug-ins are being
However, the implementation of certification mechanism is weak, and
it is easy to write a plug-in that will look like one certified by
Adobe, and so will be loaded even in 'certified' mode. Such plug-in
can execute ANY code -- i.e. perform file operations (read, write,
execute etc), access Windows Registry etc.
At 03/25/2003, vendor (Adobe Systems Inc) issued "Vendor Statement",
confirming the existence of the vulnerability:
There, vendor notes:
"The security mechanism for loading certified plug-ins will be
updated in an upcoming release of Adobe Acrobat and Adobe Acrobat
Reader available in the second quarter of 2003."
In June 2003, new versions of Adobe Reader (6.0) became available,
but it is still vulnerable. The details are below.
There are two runtime modes for which they are enabled to load and
- Non-certified mode
- Certified mode
Non-certified mode has not been changed: new versions of Adobe
Acrobat and Adobe Reader still load all third party plug-ins that
have old signatures, including "forged" ones (as described in
Certified mode has been improved, as promised: now the digital
signatures (enabling key) uses stronger algorithms, and so cannot be
forged. However, the whole Acrobat security model is still weak, as
Acrobat/Reader could be running in "Certified" mode in two cases:
- "Certified plug-ins only" option was turned on when Acrobat
starts. In this case Acrobat/Reader 6 loads only plug-ins with new
tamper-resistant certificates, so plug-in with "forged"
certificate could not be loaded.
- "Certified plug-ins only" option was turned off, but there is no
uncertified plug-ins available to be loaded. In this case Adobe
Acrobat loads all available plug-ins (including plug-ins without
digital signature at all). Adobe Reader requires all plug-ins to
be signed, but does not reject plug-in if it has old-style
signature. If all loaded plug-ins are certified by Adobe by new
(Acrobat 6+) certification mechanism, Acrobat/Reader automatically
switches to "Certified" mode.
Adobe Acrobat contains a special (internal) function that returns
active "Certified" status (is all loaded plug-ins are certified or
not). Let's call that function "CTIsCertifiedMode". Behavior of all
Acrobat components that requires "Certified" mode is based on the
value returned by this function.
Therefore, if plug-in with "forged" certificate is loaded, it can
patch the code of CTIsCertifiedMode function in memory, and so force
Acrobat to believe that it works in "Certified" mode.
It is not a big problem to find CTIsCertifiedMode in memory.
Plug-ins gets access to Acrobat/Reader core functions through the
set of tables called Host Function Tables (HFTs). One of such tables
has the name "CoreTools". The functions referred by that table are
not documented by Adobe, but one of the functions within CoreTools
HFT is CTIsCertifiedMode.
The impact of this vulnerability is described below.
The impact of the vulnerability
There are many Adobe Acrobat and Adobe Reader plug-ins that can load
(by design) only in certified mode. One example is all documents
protected with "Adobe DRM" security handler (so-called eBooks).
Certified more assures that all other plug-ins, loaded with those
ones, have been also certified by Adobe.
However, using the vulnerability described above, the plug-in with
forged signature can perform virtually everything, including but not
- removing or modifying any restrictions (from copying text to
Clipboard, printing etc) from the documents loaded into Adobe
Acrobat or Adobe Reader;
- remove any DRM (Digital Rights Management) schemes from PDF
documents, regardless the encryption handler used -- WebBuy,
InterTrust DocBox, Adobe DRM (EBX) etc;
- modify or remove digital signatures used within a PDF document;
- affect any/all other aspects of a document's confidentiality,
integrity and authenticity.
Systems and configurations that are vulnerable
Software: Adobe Acrobat 4.x
Adobe Acrobat 5.x
Adobe Acrobat 6.0
Adobe Acrobat Reader 4.x
Adobe Acrobat Reader 5.x
Adobe Reader 6.0
Operating systems: Windows 98
Adobe Acrobat and Adobe Reader should NOT be able to load ANY
plug-ins that have old (designed for versions 4 and 5) certificates.
All plug-ins for version 6 should use new, improved signatures.
Besides, Acrobat/Reader should verify the integrity of its own
executable code in memory, refusing to run (or just to load
plug-ins) if the code has been modified.
Unfortunately, Adobe does not pay much attention to vulnerability
report. The official response usually is:
"Adobe will evaluate this report, as we do any report we receive. For
security reasons, Adobe can't discuss the measures we take as a
result. Security is an ongoing effort. We are committed to
strengthening the security of our products by using sophisticated,
industry-standard levels of software encryption and working with the
software community, including 'White Hat' security experts, to
incorporate features to advance the quality of our products. However,
no software is 100 percent secure from determined hackers."
To implement reliable and secure solutions, it is not enough just to
"use sophisticated, industry-standard levels of software encryption"
- it is necessary to use them *properly*. It is well known that the
chain is as weak as it's weakest link.