Home page logo
/

bugtraq logo Bugtraq mailing list archives

ZLib double free bug: Windows NT potentially unaffected
From: "KJK::Hyperion" <noog () libero it>
Date: Thu, 14 Mar 2002 18:52:13 +0100

ZLib implementations on Windows NT should be unaffected by the "double free" bug, as long as they use the heap management functions of the Runtime Library (RTL), or any front-end to them, since these functions do a pretty good job at preventing heap corruption and access violations

The impact of this should not be understimated:
- virtually no Windows user, and most administrators as well, knows what libraries are used by a program. Many vendors seem to keep such information hidden and secret anyway, go figure - this is worsened by the fact that almost all programs using ZLib link statically to it, since there's no official version of it shipped with Microsoft Windows, even if it got more and more popular. This makes even more difficult finding what programs use ZLib. The only way is searching executables for well-known strings in the ZLib source code (if such strings exist, since error messages may have been localized) - even worse: many users install and use regularly very old or "dead" (no longer maintained) pieces of software, or obsolete versions. The only way to update this kind of software, in most cases, is to crack it. Users can't really be blamed for this: vendors bastardizing, crippling, perverting, bloating, otherwise worsening their software across versions and/or releases, or discontinuing support for very popular software, or unexpectedly changing licensing scheme, or otherwise forcing, or giving good reasons to their users not to update the software should

In short: updating Windows software based on historical libraries without an official distribution is very, very, very difficult

Proof of concept:

#include <windows.h>
#include <stdio.h>

int main(void)
{
 void * pTest;

 /* allocate 4KB of heap memory */
 pTest = HeapAlloc(GetProcessHeap(), 0, 0x1000);

 /* free it twice */
 HeapFree(GetProcessHeap(), 0, pTest);
 HeapFree(GetProcessHeap(), 0, pTest);

 /* allocate some memory again */
 pTest = HeapAlloc(GetProcessHeap(), 0, 100);

 printf("0x%08X\n");

 /* free the memory */
 HeapFree(GetProcessHeap(), 0, pTest);

 /* if we reach this point, the heap should be intact */
 return (0);
}

I allocate 4 kb of memory, then I free the block twice. Under debugging, this program will emit the following diagnostic message:

HEAP[testheap.exe]: Invalid Address specified to RtlFreeHeap( 130000, 1357f0 )

immediately after this, a breakpoint exception (code 0x80000003) is raised. So, apparently, the second free operation degrades gracefully, apparently without any corruption of in-memory structures, since the subsequent allocation/deallocation runs fine

NOTES:
1 - test machine: Windows 2000 Professional, Service Pack 2, various hotfixes
2 - unsure about "mixed-blood" Windows systems (Windows 95 family), but they should share a good part of the RTL with NT, heap manager included (hopefully) 3 - my proof-of-concept is oversimplified, and may or may not demonstrate that the NT RTL heap manager is not vulnerable to "double free". Further testing by more talented and motivated hackers is welcome
4 - Win32 functions based on the Rtl heap manager are:
Legacy memory management functions (only when using fixed blocks - I can give you no guarantee about moveable blocks):
 - GlobalAlloc
 - GlobalFree
 - GlobalReAlloc
 - GlobalSize
 - LocalAlloc
 - LocalFree
 - LocalReAlloc
 - LocalSize

Heap management functions:
 - HeapAlloc
 - HeapCompact
 - HeapCreate
 - HeapDestroy
 - HeapFree
 - HeapLock
 - HeapReAlloc
 - HeapSize
 - HeapUnlock
 - HeapValidate
 - HeapWalk

Any malloc/realloc/free implementation based on these functions should be relatively safe from heap corruption


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault