A few days ago, a postto a vulnerability discussion mailing list included a demonstration ofa heap corruption in Windows .hlp files' "bm" section. .hlp files areWinHelp-format Help files, a primitive version of .chm, or CompiledHelp Module-format help files. The "bm" section, or the Bitmap-formatgraphics section, is the part of the .hlp file that contains graphics(icons, pictures, etc.). The poster had discovered the vulnerability byusing a fuzzer to insert random data into the file. However, it seemsthat he did not understand why this vulnerability works.
After digging into the issue, it appeared to me that the filetargets the same vulnerability that was last attacked in December of2004, the WinHelp Phrase Heap Overflow.However, after a careful review, I realized that this heap overflow isnot the same as the one posted, so this appears to be the firstdisclosure after all.
The actual vulnerability discovered was that the LZ77decompressor does not check the size of the destination buffer. Furtheranalysis revealed that the same type of bug exists in the RLEdecompressor. The two of them are used by almost every section in .hlpfiles, meaning that the vulnerability isn't specific to the "bm"section. Although the LZ77 and RLE decompressor algorithms are widelyused by a variety of programs, the vulnerability is specific toMicrosoft's implementation in the Winhlp32.exe program. Additionally,this bug appears to be present in the 16-bit versions of Winhelp.exe,which means that it has gone undetected for over 15 years!
These two bugs are not the only vulnerabilities, though. I found twoothers that are actually specific to the bm section of .hlp files.Microsoft has opened a case for these, and we'll see what happens;however, according to
KB925330, Microsoft already considers .hlp to be an unsafe file type, so these vulnerabilities may not be patched.