Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

Vulnerability (critical): Digital signature for Adobe Acrobat/Reader plug-in can be forged

From: Vladimir Katalov <info(at)elcomsoft.com>
Date: Mon Mar 24 2003 - 06:56:14 EST


-----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                : info@elcomsoft.com
  WWW:                  : 
http://www.elcomsoft.com

  The problem has been reported to the vendor (Adobe Systems Inc):

Do you need help?X

  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.

Do you need more help?X

  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.

Can we help you?X

  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.

Can't find what you're looking for?X

-----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----- Received on Mon Mar 24 13:26:19 2003

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:38 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library