4th Mar 2003 [SBWID-6039]
COMMAND
Implementation flaws in Adobe Document Server for Reader Extensions
SYSTEMS AFFECTED
Free Adobe Acrobat Reader (version 5.1 or later)
PROBLEM
Summary
===============================================================================
Free Adobe Acrobat Reader (version 5.1 or later) has ability to: add
notes and attachments, add and check digital signatures, save forms
locally, fill them out online, distribute to others for review and
commenting, and submit forms via e-mail or the Web directly from within
Acrobat Reader. But actions listed above available for rights-enabled
documents only (i.e. documents processed by Adobe Document Server for
Reader Extensions). Improper usage of cryptography in server software
allows anyone to produce reader-enabled documents without Document
Server for Reader Extensions.
Contact information
===============================================================================
Name : ElcomSoft Co.Ltd.
E-mail : info@elcomsoft.com
Fax : +1 866 448-2703 (US/Canada, toll-free)
The problem has been reported to vendor (Adobe Systems Inc) on
02/24/2003; vendor has not replied.
Technical info
===============================================================================
Adobe Document Server for Reader Extensions
-------------------------------------------------------------------------------
With this server, customers can assign custom usage rights to specific
Adobe Portable Document Format (PDF) forms and documents, so Acrobat
Reader 5.1 users can get access to additional features while working
with the document. The server can enable four types of usage rights on
a PDF form:
- Commenting tools, including sticky notes, highlights, stamps, and
strikethroughs;
- The ability to save a form to a desktop for offline completion or archiving,
without loosing any forms data;
- Digital signatures, including support for Public Key Infrastructure systems
for third-party validation (VeriSign, Entrust, and others);
- Advanced form features, including the ability to submit a form offline or via
email, import or export forms data and attached files.
Description of Adobe Document Server for Reader Extensions features is
available at
http://www.adobe.com/products/server/readerextensions/main.html.
The implementation of Document Server for Reader Extensions does not
seem to be very complicated. The Server just gets the PDF file (to be
reader-enabled) together with the list of enabling options, and
produces new document that contains one additional dictionary -
actually, simply by adding an additional block of data.
Note: for details of PDF structure, see Portable Document Format
Specification
http://partners.adobe.com/asn/developer/acrosdk/docs/filefmtspecs/PDFReference.pdf
New dictionary is named "ViewerPreferences" and resides within
document's "Root" dictionary. For now, only one element is placed
inside "ViewerPreferences" dictionary - "Rights" Dictionary. Content of
the "Rights" Dictionary can be described as follows (key name, type and
description):
"Version" (number): A number specifying the version of Rights dictionary.
Currently only version 1 is supported.
"Document" (array of names): List of flags related to Document operations.
Currently only one flag is supported: FullSave.
"Form" (array of names): List of flags related to Form processing. Supported
flags: Import, Export, SubmitStandalone, SpawnTemplate.
"Annots" (array of names): List of flags related to Annotations. Supported
flags: Create, Delete, Modify, Copy, Import, Export.
"Signature" (array of names): List of flags related to Digital Signature
handling. Currently only one flag is supported: Modify.
"Msg" (text string): Arbitrary string to be displayed in "Instructions" box
when reader-enabled document is opened in Acrobat Reader 5.1.
"TimeOfUbiquitization" (date): The date and time when document was processed
by Document Server for Reader Extensions.
"RightsID" or "ADBE_RightsID" (array): List of RSA-based digital signatures
for checking integrity of reader-enabling attributes.
Most elements listed in the table above are self-descriptive. Name of
the last key could be either RightsID or ADBE_RightsID - they are
equivalent in Reader 5.1. Values in RightsID (or ADBE_RightsID) array
are 512-bit RSA-encrypted values, and could be decrypted with RSA
Public Key, which is hard-coded (in encrypted form) within Reader 5.1
executable. Those values are used as digital signatures of some
critical document parts to make sure that document was reader-enabled
with Adobe Document Server for Reader Extensions.
Sample form with additional usage rights could be downloaded from
http://www.adobe.com/products/server/readerextensions/pdfs/sample_docserver_readerext.pdf
According to press release from October 21, 2002, available at
http://www.adobe.com/aboutadobe/pressroom/pressreleases/pdfs/200210/20021021Ubiquity.pdf,
pricing of Adobe Document Server for Reader Extensions starts at
US$75,000.
Adobe Acrobat Reader
-------------------------------------------------------------------------------
Adobe Acrobat Reader is the most popular part of Adobe Acrobat product
family. Acrobat Reader is free and can be downloaded from Adobe Systems
Incorporated web site
http://www.adobe.com/products/acrobat/readermain.html.
Other most interesting (for this statement) products from Adobe Acrobat
family are commercial Adobe Acrobat ($249) and Adobe Acrobat Approval
($39). Comparison of the free Acrobat Reader 5.1 with Acrobat 5.0 and
Acrobat Approval could be found at Planet PDF web site:
http://www.planetpdf.com/mainpage.asp?webpageid=2413.
For a long time Acrobat Reader was just "the reader" - its ability of
editing was limited to form filling, but there was no way to get
altered copy of the document on disk. Acrobat Reader 5.1, however,
includes some new functions, that extend Reader functionality, and make
it very close to commercial Acrobat Approval. In other words, new
Acrobat Reader 5.1 is something like a limited version of Acrobat
Approval with functional restrictions applied to all documents except
reader-enabled ones.
When the document is opened in Acrobat Reader 5.1, the Reader looks
inside ViewerPreferences/Rights dictionary, and based on information
found there, enables some editing features (or keep them disabled).
The problem
-------------------------------------------------------------------------------
As noted earlier, 512-bit RSA encryption is being used to prevent
creating reader-enabled documents without Adobe Document Server for
Reader Extensions. 512-bit RSA keys are not considered to be absolutely
non-breakable - in 1999 a group of researchers completed the
factorization of the 512-bit RSA Challenge Number in 5.2 months (see
http://www.rsasecurity.com/rsalabs/challenges/factoring/rsa155.html for
details). But it seems that building a system for breaking RSA-512 is
more expensive than obtaining Document Server for Reader Extensions
from Adobe. So, 512-bit RSA is sufficient for such application. But, as
it often happens, implementation corrupts the idea.
"RightsID" key from "Rights" Dictionary usually contains three values.
First value is a signature for the "Rights" Dictionary content
(excluding "RightsID"/"ADBE_RightsID" key itself), "CreationDate",
"Producer" and "Creator" keys from PDF Info Dictionary, and Document ID
from PDF Trailer Dictionary. Second and third values from "RightsID"
key are signatures of the first and the last pages of PDF document
content, respectively.
The document is considered to be enabled properly only when the
"Rights" Dictionary signature and at least one Page Content signature
are correct.
Let's starts the research with page content signature calculation.
At the first stage, every byte of decompressed page content (but not
more than 1024 bytes) is passed through the hash function. Hash is not
too complicated - some non-printable characters (such as Space, Tab,
CR, LF) are ignored, and ASCII-codes of all remaining characters are
added to 32-bit counter, initially set to zero.
At the second stage, the 32-bit value calculated as described above
(actually, the largest possible value contains only 18 significant
bits) is converted to 8-byte hexadecimal representation, and "PaGeS"
string is appended to the end. Resulting 13-byte sequence is processed
with MD5 hash function, which produces 128-bit (16-byte) page
fingerprint.
At the last stage, 512-bit RSA Private Key (stored somewhere in Server)
is used to encrypt page fingerprint. Encrypted value is stored in
"RightsID" array. To verify Page Content signature, the Reader
calculates page fingerprint and compares it with the value decrypted
using RSA Public Key.
Obviously, the signature calculation procedure described above is not
perfect. Adding "PaGeS" string does not affect the reliability at all.
But it is looks like a sort of tradition in Adobe: in undocumented
version of key calculation algorithm (V3), used by Standard Security
Handler in Adobe Acrobat 5, string "sAlT" has been used in the same way
- instead of the real "salt" value, that should be totally random.
But the most significant problem with Page Content signature
calculation is: it is very easy to build 1024-byte sequence of
characters, treated as comments by PDF interpreter, so the sum of all
characters in that sequence will be the same as the sum of first 1024
characters in any reader-enabled document. So, inserting such comment
before any page will produce a new page, interpreted exactly like
original one, with fixed (known) signature value. Let's pay some
attention to the "Rights" Dictionary signature calculation.
During that operation, some 32-bit hash (not cryptographic one, but a
little bit more complicated than just addition) is calculated from all
keys of the "Rights" Dictionary excluding "RightsID" array. Hash value
is converted to hexadecimal representation and passed through MD5 hash
function along with the values from PDF Info Dictionary such as
"CreationDate", "Producer" and "Creator", and constant string "Adobe
Acrobat". First five bytes of MD5 output are treated as a key for RC4
symmetric stream cipher, which is used to encrypt Document ID from PDF
Trailer Dictionary. Encrypted ID is encrypted again with RSA Private
Key to produce "Rights" Dictionary signature that should be stored as
the first element of the "RightsID" array.
This procedure looks not too bad in comparison with Page Content
signature calculation, but not perfect too. Now, the problem is related
to Document ID and RC4. It is well known that RC4 (like many other
stream ciphers) is just a pseudo-random sequence generator, and
generated stream is combined with source data by XOR operation to
produce encrypted data. Therefore, if we need to force "Rights"
Dictionary signature to be equal to some predefined value, the
following approach should work:
- Decrypt signature (from any reader-enabled document) by RSA Public Key to
obtain RC4-encrypted Document ID;
- Calculate "Rights" Dictionary and Info Dictionary hash (from document to be
reader-enabled) to obtain RC4 key;
- Decrypt Document ID value by RC4 and assign it to the new document.
It is necessary to note that Document ID consists of two parts:
permanent identifier and variable identifier. Only permanent identifier
is involved in the signature calculation. The Document ID is used to
resolve external references by ID, and almost useless in "standalone"
documents. So, assigning the new Document ID is not a big issue.
Impact
===============================================================================
As it was shown above, all 512-bit RSA-based signature checks could be
easily bypassed - it is very difficult to break RSA-512 cipher itself
and calculate signature values for arbitrary document, but it is much
easier to modify document to match a fixed (known) signature values
without noticeable changes in the document's content, and without
breaking, stealing or purchasing RSA private key.
It is looks like the only party negatively affected by such facts is
Adobe Systems Incorporated itself. But if some U.S. government agency
will decide to spend $75K for Adobe Document Server for Reader
Extensions, all U.S. taxpayers will be affected by indirection, too.
SOLUTION
?
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
