|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Adobe Acrobat and PDF security: no improvements for 2 years
Date: Tue Jul 08 2003 - 06:38:57 EDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5
Adobe Acrobat and PDF security: no improvements for 2 years. Software released in 2003 contains vulnerabilities disclosured in 2001
July 8, 2003
SUMMARY
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.
CONTACT INFORMATION
Name : ElcomSoft Co.Ltd. E-mail : info@elcomsoft.com Web : http://www.elcomsoft.com Phone / fax : +1 866 448-2703
HISTORY
Adobe Systems Inc is referred as "Vendor" ElcomSoft Co.Ltd. is referred as "Reporter"
07/16/2001: "eBook Security: Theory and Practice" presentation on
DefCon 9:
http://www-2.cs.cmu.edu/~dst/Adobe/Gallery/defcon.ppt
06/13/2002: Report sent to vendor
(PASSKEY:75DF62C56A7DE9F888256BCB0001DF72)
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
details;
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
release
12/04/2002: Initial date identified for potential publication of the
report
12/09/2002: Vendor replies that their response is undergoing legal
review
12/18/2002: Reporter asks for status update; notes 45-day disclosure
period over
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
status
03/19/2003: CERT Vulnerability Note (VU#549913) published:
http://www.kb.cert.org/vuls/id/549913 03/25/2003: Vendor Statement (JSHA-5EZQGZ) published:
http://www.kb.cert.org/vuls/id/JSHA-5EZQGZ 07/02/2003: Updated vulnerability report by reporter to CERT 07/04/2003: Updated vulnerability report sent by reporter to vendor
TECHNICAL DETAILS
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 loaded.
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: http://www.kb.cert.org/vuls/id/JSHA-5EZQGZ
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 execute:
- 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 VU#549913).
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 described below.
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 limited to:
- 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
Windows ME
Windows 2000
Windows XP
Possible solutions
- ------------------
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.
CONCLUSION
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.
-----BEGIN PGP SIGNATURE-----
Version: 2.6
iQEVAwUAPwqfHMGOU/F25e8NAQErmggAwtT8+afiS3rFvxX+7QAk4SINVDdZjEQz
Dd2ZZgdLbq0zLWs37CX92F3V6JjvsFFbZXe+NHPZr4begdAnXeF/oV8j8C5rLfs2
YiBmO8SMoS7R/PKWjaJH7/XpCOLbSiyuVH2ndHZYM6U19fp1vE9zfP/6wMq5y24o
FW5+63Bofn5o8V46my0uMPSQJTnrx8NZzprNVI4Jx0OddR6ULi5GF5qLDcOyaj4P
2L9l5pCMCzLZo0iTQb7qPujt+RSNOhmlk8mFfefJ6Pr8E/llY4uqhGLAv774be5m
jfw/78G36PNrN2xGlFJ7ww2yxm/7RI7bBU6HLJpZ2EAhYkfnQwrZXQ==
=O1wf
-----END PGP SIGNATURE-----
Received on Tue Jul 8 18:19:24 2003
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:40 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |