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
This archive was generated by hypermail 2b30 : Thu Mar 14 2002 - 16:58:51 PST