[NEWS] Digital Signature for Adobe Acrobat/Reader plug-in can be Forged

From: support@securiteam.com
Date: 03/26/03

  • Next message: support@securiteam.com: "[NT] Flaw in RPC Endpoint Mapper Could Allow Denial of Service Attacks" 
    From: support@securiteam.com
To: list@securiteam.com
Date: 26 Mar 2003 18:07:38 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    In the US?

    Contact Beyond Security at our new California office
    housewarming rates on automated network vulnerability
    scanning. We also welcome ISPs and other resellers!

    Please contact us at: 323-882-8286 or ussales@beyondsecurity.com
    - - - - - - - - -

      Digital Signature for Adobe Acrobat/Reader plug-in can be Forged
    ------------------------------------------------------------------------

    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 is signed by Adobe using their own private Key, and there is a
    'trusted' mode in Acrobat, when only Adobe-certified plug-ins is 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.

    DETAILS

    Vulnerable systems:
    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.

    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.

    However, certificate-checking algorithm makes decision about certificate
    validity upon plug-in's Portable Executable header only. Therefore, 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 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 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.

    Impact:
    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 content 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.

    Vendor status:
    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 estimation when the
    problem will be fixed.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:info@elcomsoft.com> Vladimir
    Katalov of ElcomSoft Co.Ltd.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: support@securiteam.com: "[NT] Flaw in RPC Endpoint Mapper Could Allow Denial of Service Attacks"

    Relevant Pages