-----BEGIN PGP SIGNED MESSAGE----- Hash: MD5 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 : infoat_private 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. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQEVAwUAPn7yYsGOU/F25e8NAQGlDQf/SZR5XRTj4T4HHeTGX9dQJLkGqZBa1yyz RGRLsWwIQaI1trBbmr5pi/5vRHYjsdhyUlIgh/F7Zr+xJ+F6417lNwZAE3kC+1oU xilISkFsFyriY/zzWEBj/hCjk4w2Iaum0VeL8cmvHvFVgPUs2uOeNdHBHH0olbB+ aKriAqrSWOwsaooAY9EKe2QO1VXETlo6AalGBy/hqyxzint2yhE7/coqrZRV/QKZ V95h5OQ4OIc6RAwJociZJJnzr97F1GEXdksCXqS2XgAMiEy8bfDTBmmHnEc8C84U A1k8D/Q2dy3mcMnVneo6O6fH4iLXAJ7KSNaFBH78cWtFGG4TnhReaA== =hCEQ -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Mon Mar 24 2003 - 10:26:01 PST