13th Dec 2002 [SBWID-5874]
COMMAND
PNG Deflate Heap Corruption Vulnerability via pngfilt.dll
SYSTEMS AFFECTED
Marc Maiffret says :
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
PROBLEM
<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.
SOLUTION
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 alert@eEye.com 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
info@eEye.com
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
