ZLib double free bug: Windows NT potentially unaffected

["KJK::Hyperion" <noog () libero it>]

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