Previous | Next | (P-PDF) General
Topic: Vulnerability (critical) in digital signatures for Adobe plug-ins
Conf: (P-PDF) General, Msg: 84886
From: vkatalov
Date: 3/25/2003 08:02 PM
Vulnerability (critical): Digital signature for Adobe Acrobat/Reader plug-in can be forged
March 24, 2003
SUMMARY
===============================================================================
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
'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 'trusted' mode. Such plug-in can execute ANY code
-- i.e. perform file operations (read/write/execute), access Windows
Registry etc.
CONTACT INFORMATION
===============================================================================
Name : ElcomSoft Co.Ltd.
E-mail : info@elcomsoft.com
WWW: : http://www.elcomsoft.com
The problem has been reported to the vendor (Adobe Systems Inc):
07/16/2001 on DefCon security conference
06/13/2002 directly by email to the vendor
(PASSKEY:75DF62C56A7DE9F888256BCB0001DF72)
At 09/10/2001, the report has been sent to CERT Coordination Center, and
reported to Vendor by CERT:
10/08/2002 web feedback
10/18/2002 follow up to PR contact(s)
11/26/2002 follow up with vendor to get status of report
01/21/2003: Private CERT Vulnerability Card published with draft status
Only at 12/09/2002, vendor replied that their response is undergoing legal
review. In January 2003, Vendor has confirmed that they recognize the
problem, but still fail to fix it, or even make an estimation when the
problem will be fixed.
CERT Vulnerability Note (VU#549913) is now online:
http://www.kb.cert.org/vuls/id/549913
TECHNICAL INFO
===============================================================================
Description of the vulnerability
--------------------------------
Adobe provides plug-ins SDK and plug-ins certification (signing) mechanism.
Adobe Acrobat Reader can only load plug-ins signed with "Reader
Integration Key", and in some critical cases both Adobe Acrobat and
Adobe Acrobat Reader load only plug-ins certified as "trusted" (signed
by Adobe itself), that is, plug-ins that respect the security settings
of the document.
But certificate checking algorithm makes decision about certificate
validity upon plug-in's Portable Executable header only. So, any
correction in plug-in code will pass unnoticed.
Moreover, it is possible to modify certified plug-in to load any
other plug-in, and pass control to it. Hence, any plug-in could be
loaded as if it was certified by Adobe, making certification
completely useless.
We were able to write a 'fake' plug-in "fakecert.api" which does
nothing, but being loaded by Adobe Acrobat (and Reader) 4 and 5
as the certified one even in 'trusted' mode, though we don't have
a 'Reader Integration Key' (this plug-in has been provided only to
Adobe and CERT). When installed into 'plug_ins' subfolder, plug-in
is being loaded every time when Adobe Acrobat (or Reader) starts, and
shows a simple message box.
Technical information (how it was written) follows:
If we have completed 'IMAGE_NT_HEADERS peHdr' structure, here is the
data that goes through MD5 hashing routine (in the given order):
WORD peHdr.FileHeader.NumberOfSections
WORD peHdr.FileHeader.Machine
DWORD peHdr.FileHeader.PointerToSymbolTable
DWORD peHdr.FileHeader.NumberOfSymbols
WORD peHdr.FileHeader.SizeOfOptionalHeader
WORD peHdr.FileHeader.Characteristics
WORD peHdr.OptionalHeader.Magic
BYTE peHdr.OptionalHeader.MajorLinkerVersion
BYTE peHdr.OptionalHeader.MinorLinkerVersion
DWORD peHdr.OptionalHeader.SizeOfCode;
DWORD peHdr.OptionalHeader.SizeOfInitializedData;
DWORD peHdr.OptionalHeader.SizeOfUninitializedData;
DWORD peHdr.OptionalHeader.AddressOfEntryPoint;
DWORD peHdr.OptionalHeader.BaseOfCode;
DWORD peHdr.OptionalHeader.BaseOfData;
DWORD peHdr.OptionalHeader.SizeOfImage;
DWORD peHdr.OptionalHeader.SizeOfStackReserve;
DWORD peHdr.OptionalHeader.SizeOfStackCommit;
DWORD peHdr.OptionalHeader.LoaderFlags;
DWORD peHdr.OptionalHeader.NumberOfRvaAndSizes;
for (i = 0; i < IMAGE_NUMBEROF_DIRECTORY_ENTRIES; i++) {
IMAGE_DATA_DIRECTORY peHdr.OptionalHeader.DataDirectory[i];
}
The important elements are: number of sections, size of
code/data/image, entry point address, and IMAGE_DATA_DIRECTORY
(addresses and sizes of import table, export table, relocations etc).
It is really easy to defeat all these checks by just 'applying' his
characteristics to our plug-in (which we would like to make
'certified').
Number of sections: as far as Acrobat does not verify the attributes
(name, RVA, address in the file, length, flags) and contents of the
sections, we can merge a few sections into a single one, or create
additional (empty) sections as needed, so the total number of sections
will be the same as in the real (certified) plug-in.
Size of code/data/image: there are two workarounds. First, we can
select the Adobe plug-in that is large enough (so our own code would
fit into it); or make the code small and move the most functionality
into the external DLLs.
Needed entry point address can be achieved by inserting 'jmp'
instruction at the address of the certified plug-in. Some manual work
might be needed (if there is some important code at this address
already).
No problems at all with IMAGE_DATA_DIRECTORY. In most cases, PE loader
just ignores the size set in Directory. Besides, the mandatory data
for that address is just a small import/export table, and all other
data could be stored in some other place. So it is enough (to fool the
certification checks) to put resources/Relocations/Import/Export at
the needed addresses, and fix some references manually.
The impact of this vulnerability
--------------------------------
1. One of the purposes of Adobe plug-in certification system is an
ability to identify an author/developer of any plug-in used by
Acrobat Reader. However, using the method described above, it is
possible to use bogus digital certificate to forge digital signature,
or to 'certify' any plug-in using certificate that actually
has been issued to another (trusted, well-known) developer such as
SoftLock, FileOpen etc., so making impossible to identify the real
authorship of plug-in.
2. Plug-ins have full access to the system, i.e. can read/write files,
execute any code etc. The 'trusted' mode in Adobe Acrobat/Reader
should be safe (by design), because only Adobe-certified plug-ins
are being loaded; however, as shown above, any plug-in can be
manually 'signed' as Adobe's, and so it will be loaded regardless
security settings in Adobe software. All plug-ins have some kind of
start-up code that is being executed immediately when Acrobat/Reader
is started (and so plug-in is loaded), but that code may include
malicious/arbitrary routines such as viruses, trojan horses etc.
Alternatively, plug-in itself can perform such useful operations, but
contain a malicious code that will be activated only when specific
PDF file (e.g. downloadable from the Internet, or sent by email as
attachment) is being opened.
3. 'Trusted' mode is activated automatically by Adobe Acrobat/Reader
when it loads documents that are protected using various DRM (Digital
Rights Management) schemes such as WebBuy, InterTrust DocBox etc -- to
prevent protected contect from being saved with protection stripped.
However, a plug-in with 'fake' certificate can be loaded anyway, and
so it will be able to do anything with DRM-protected documents, e.g.
altering or removing security options.
Systems and configurations that are vulnerable
----------------------------------------------
These versions of Adobe Acrobat/Reader are vulnerable on Win32 platform
(Windows 95/98/ME/NT/2000/XP):
Adobe Acrobat 4.x
Adobe Acrobat 5.x
Adobe Acrobat Reader 4.x
Adobe Acrobat Reader 5.x
We have not tested non-Win32 versions, but it seems that they're
vulnerable, too.
