Re: ZLib double free bug: Windows NT potentially unaffected

From: Martijn Lievaart (mat_private)
Date: Fri Mar 15 2002 - 04:15:37 PST

  • Next message: Casper Dik: "Re: OpenSSH rebuild warning: problems avoiding zlib problems in Solaris"

    Robert Collins wrote:
    > 
    >>-----Original Message-----
    >>From: KJK::Hyperion [mailto:noogat_private] 
    >>Sent: Friday, March 15, 2002 4:52 AM
    >>To: bugtraqat_private
    >>Subject: ZLib double free bug: Windows NT potentially unaffected
    >>
    >>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
    >>
    > 
    > Can I suggest you try it with a non-debug build. I've seen heap
    > corruption occur in winNT software, that in debug-builds was trapped,
    > but in non-debug builds was not.
    > 
    
    Actually, this is one of the big differences between debug and non-debug 
    builds with MSVC.  Note the name of the routine above, it is 
    RtlFreeHeap. This is the MSVC RTL, not WindowsNT memory management.
    
    The MSVC debug builds check for heap corruption on all heap operations, 
    as demonstrated above. Non-debug builds don't check, they just assume 
    that everything is valid. In this case, the pointer passed to free is 
    /not/ valid, which only the debug build will catch. The non-debug build 
    could do anything, most likely crash, but almost equally likely it runs 
    as if there was no bug.
    
    I'm not sure this would be exploitable though.
    
    Martijn Lievaart
    



    This archive was generated by hypermail 2b30 : Fri Mar 15 2002 - 14:54:23 PST