[ISN] PNG (Portable Network Graphics) Deflate Heap Corruption Vulnerability

From: InfoSec News (isnat_private)
Date: Thu Dec 12 2002 - 00:47:20 PST

  • Next message: InfoSec News: "[ISN] Security UPDATE, December 11, 2002"

    Forwarded from: Marc Maiffret <marcat_private>
    
    PNG (Portable Network Graphics) Deflate Heap Corruption Vulnerability
    
    Release Date:
    December 11, 2002
    
    Severity:
    High (Code Execution)
    
    Systems Affected:
    We have specifically tested the following software and verified the
    potential for exploitation:
    Microsoft Internet Explorer 5.01
    Microsoft Internet Explorer 5.5
    Microsoft Internet Explorer 6.0
    
    Note: We have also successfully exploited this vulnerability via the IE web
    control for Microsoft Outlook.
    
    For the purpose of completeness we have included a listing of each product
    that ships with the vulnerable pngfilt.dll version 6.0.2600.0 and prior. We
    obtained this list from Microsoft's DLL Help Database:
    
    Access 2000 SR1
    BackOffice 4.5
    Commerce Server 2000
    DirectX 6.0 SDK
    DirectX 6.0 SDK
    Internet Explorer 4.0
    Internet Explorer 4.01 SP1
    Internet Explorer 4.01 SP1
    Internet Explorer 4.01 SP2
    Internet Explorer 4.01 SP2
    Internet Explorer 5.0
    Internet Explorer 5.01
    Internet Explorer 5.5
    Internet Explorer 5.5 Service Pack 2
    Internet Explorer 6.0
    Microsoft Visual Studio .NET (2002) Enterprise Architect
    Microsoft Visual Studio .NET (2002) Enterprise Architect
    Microsoft Visual Studio .NET (2002) Enterprise Developer
    Microsoft Visual Studio .NET (2002) Professional
    Office 2000 Developer
    Office 2000 SR1
    Office 2000 SR1
    Office XP Professional
    Project 2002 Professional
    Publisher 98
    Publisher 98
    SNA Server 4.0 SP2
    SNA Server 4.0 SP2
    SNA Server 4.0 SP3
    SNA Server 4.0 SP3
    SQL Server 7.0
    SQL Server 7.0
    SharePoint Portal Server
    Small Business Server 2000
    Small Business Server 2000
    Visio 2002 Professional
    Visio 2002 Standard
    Visual Basic .NET Standard 2002
    Visual C# .NET Standard 2002
    Visual C++ .NET Standard 2002
    Visual FoxPro 7.0
    Visual Studio 6.0
    Visual Studio 6.0
    Visual Studio 6.0 SP4
    Visual Studio 6.0 SP5
    Windows 2000 Datacenter Server
    Windows 2000 Professional
    Windows 2000 Server
    Windows 95 OSR 2.5
    Windows 95 OSR 2.5
    Windows 98
    Windows 98 Second Edition
    Windows Millenium Edition
    Windows NT 4.0 SP5
    Windows NT 4.0 SP5
    Windows XP Home 2002
    Windows XP Professional 2002
    
    <Preamble>
    
    Twas the night before Christmas, and deep in IE
    A creature was stirring, a vulnerability
    MS02-066 was posted on the website with care
    In hopes that Team eEye would not see it there
    
    But the engineers weren't nestled all snug in their beds,
    No, PNG images danced in their heads
    And Riley at his computer, with Drew's and my backing
    Had just settled down for a little PNG cracking
    
    When rendering an image, we saw IE shatter
    And with just a glance we knew what was the matter
    Away into SoftICE we flew in a flash
    Tore open the core dumps, and threw RFC 1951 in the trash
    
    The bug in the thick of the poorly-written code
    Caused an AV exception when the image tried to load
    Then what in our wondering eyes should we see
    But our data overwriting all of heap memory
    
    With heap management structures all hijacked so quick
    We knew in a moment we could exploit this $#!%
    More rapid than eagles our malicious pic came --
    The hardest part of this exploit was choosing its name
    
    Derek Soeder
    Software Engineer
    eEye Digital Security
    
    </Preamble>
    
    
    Overview:
    During a review of the PNG image format implemented in Microsoft Windows,
    two separate vulnerabilities were discovered related to the interpretation
    of PNG image data. The first vulnerability deals with the handling of the
    IDAT header and does not appear to be of significant threat level. The
    second vulnerability can be exploited to execute code when the malicious PNG
    image is viewed.  Due to the complexity of each of these vulnerabilities we
    have decided only to describe the latter in detail.
    
    General Description:
    A heap corruption vulnerability exists due to the way the function
    inflate_fast(), within pngfilt.dll, handles certain invalid data
    present in "deflate" data input streams in a PNG image file.  The
    "deflate"  compression specification allows for the repetition of
    patterns that occur in the decompressed data. This is accomplished by
    specifying a pair of special codes that tell the decompression routine
    how far back into the decompressed stream the pattern occurred
    (distance code), and the length of the pattern to repeat in bytes
    (length code).  The inflate_fast() routine does not properly handle
    length codes marked in the specification as invalid, and as a result,
    a pattern can be replicated over a large portion of the heap, allowing
    a skilled attacker to redirect the execution of a thread into a
    "deflated" payload embedded in the deflate datastream within the
    malicious PNG image.
    
    Technical Description:
    The heap overflow described above occurs in the interpretation of a
    compressed block that uses fixed Huffman codes (BTYPE = 1).  Length codes
    #286 and #287, while labeled as invalid in the formal specification (RFC
    1951), are not discarded by the inflation routine, and are instead treated
    as zero-length codes.  However, due to the way the inflation routine is
    designed (see below), the length counter is decremented prior to being
    evaluated, and an integer overflow will occur.  As a result, the loop will
    attempt to repeat the pattern we specify over all 4GB (0xFFFFFFFF) of
    virtual address space, filling our 32KB output buffer and proceeding to
    overwrite process memory until finally reaching an invalid page in memory
    and producing a fault.
    
    The problem code is presented below in assembly, and C pseudo code.
    
            Pattern-repetition loop in PNGFILT.DLL. version 5.0.2920.0:
    
            69198FAF   mov         ecx,dword ptr [ebp+8]
            69198FB2   mov         cl,byte ptr [ecx]
            69198FB4   mov         byte ptr [edi],cl
            69198FB6   inc         edi
            69198FB7   inc         dword ptr [ebp+8]
            69198FBA   dec         dword ptr [ebp+0Ch]
            69198FBD   jne         69198FAF
    
            Pseudo-code representation of previous assembly:
    
            do
            {
                    *dest = *src;
                    ++dest;
                    ++src;
            }
            while (--len);
    
    After the process heap following the 32kb output buffer has been
    overwritten, numerous threads running within the Internet Explorer process
    attempt to free heap blocks whose memory management structures have been
    overwritten.  By supplying a carefully crafted memory management header, we
    can alter any 32-bit address to which we have write access in Internet
    Explorer's virtual address space.
    
    For the sake of demonstration, we will hijack the hook for the
    unhandled exception filter, overwriting the pointer to the handler
    with the address of a "CALL DWORD PTR [ESI+0x4C]" instruction present
    in MSHTML.DLL.  We explain the purpose of this particular instruction
    below.
    
    One of the threads that attempts to free a heap block with a memory
    management structure we now control, will cause the unhandled exception
    filter hook to be overwritten and will then cause an exception to be thrown
    by accessing an invalid address. This exception is thrown due to the
    following code sequence within RtlAllocateHeap() in NTDLL.DLL:
    
            77FCB3F5   mov     [ecx], eax
            77FCB3F7   mov     [eax+4], ecx
    
    During this operation the eax register is set to the address within
    MSHTML.DLL where our "call dword ptr [esi+0x4c]" resides. The ecx
    register is set to the address of the unhandled exception filter hook.
    
    After the first operation overwrites our exception filter hook, the
    second operation will generate an exception when it attempts to "mov"
    our exception handler address four bytes after the address we
    specified in the ".text" section of MSHTML.DLL. An exception is
    generated due to the fact that code sections, or ".text" sections are
    loaded into a process with read-only permissions.
    
    The exception created by this operation is unhandled. The faulting
    thread will then attempt to call the unhandled exception filter. Since
    the address of this function has been changed, execution will redirect
    to the "call dword ptr [esi+0x4c]".
    
    When an unhandled exception occurs, the unhandled exception filter is
    execut ed and receives, as an argument, an exception record. The "call
    dword ptr [esi+0x4c]" will redirect execution to an address supplied
    within the exception record. The data at this address is part of our
    decompressed stream.
    
    The repeated pattern in our decompressed stream contains the two
    addresses used to overwrite the unhandled exception filter hook, along
    with a padding instructions and an unconditional "jmp" that will
    direct execution up what is essentially a jump chain formed by the
    pattern repetition, into the beginning of our deflated datastream and
    the deflated payload of choice.
    
    During tests in our lab we noticed that under certain circumstances, race
    conditions occur that make exploitation very difficult. We developed
    intermediate solutions to these by reconstructing objects in heap so that
    the conflicting threads would continue long enough for our target thread to
    be exploited.
    
    Mitigating Factors:
    It should be noted that due to memory management system behavior across
    various Windows operating system environments, exploitation may become
    extremely difficult and in some cases unreliable.
    
    Protection:
    Retina® Network Security Scanner has been updated to check for this
    vulnerability.
    http://www.eeye.com/retina
    
    Vendor Status:
    Microsoft was contacted in August 2002. Internet Explorer Service Pack 1
    eliminates this vulnerability. Internet Explorer Service Pack 1 can be
    retrieved using the following URL:
    http://microsoft.com/windows/ie/downloads/critical/ie6sp1/default.asp
    
    Microsoft has released a security bulletin for this flaw. It is located
    here:
    http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
    bulletin/MS02-066.asp
    
    Credit:
    Discovery:
    Drew Copley, Research Engineer, eEye Digital Security
    
    Exploitation:
    Derek Soeder, Software Engineer, eEye Digital Security
    Riley Hassell, Research Engineer, eEye Digital Security
    
    Greetings:
    Hacktivismo!, Paul L. S. at UTD, JBNZ, and Kasia
    
    Copyright (c) 1998-2002 eEye Digital Security
    Permission is hereby granted for the redistribution of this alert
    electronically. It is not to be edited in any way without express consent of
    eEye. If you wish to reprint the whole or any part of this alert in any
    other medium excluding electronic medium, please e-mail alertat_private for
    permission.
    
    Disclaimer
    The information within this paper may change without notice. Use of this
    information constitutes acceptance for use in an AS IS condition. There are
    NO warranties with regard to this information. In no event shall the author
    be liable for any damages whatsoever arising out of or in connection with
    the use or spread of this information. Any use of this information is at the
    user's own risk.
    
    Feedback
    Please send suggestions, updates, and comments to:
    
    eEye Digital Security
    http://www.eEye.com
    infoat_private
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Thu Dec 12 2002 - 03:57:59 PST