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

From: Vladimir Katalov (info@elcomsoft.com)
Date: 03/24/03

  • Next message: Piotr Chytla: "[VulnWatch] 3com RAS 1500 Remote vulnerabilities."
    Date: Mon, 24 Mar 2003 14:58:22 +0300
    From: Vladimir Katalov <info@elcomsoft.com>
    To: vulnwatch@vulnwatch.org

    Hash: MD5

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

    March 24, 2003


      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

      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.


      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

      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:


    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

      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

      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.

    Version: 2.6

    -----END PGP SIGNATURE-----

  • Next message: Piotr Chytla: "[VulnWatch] 3com RAS 1500 Remote vulnerabilities."