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

Vladimir Katalov <info@elcomsoft.com> · Mon, 24 Mar 2003 14:48:58 +0300

  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.