Security Information Vulnerability Research Security Blog

IE5 *was* pre-patched to VML vulnerability

December 8th, 2006 by , Filed under: Commentary, Digest, Microsoft

As I was researching for ZERT to patch the VML vulnerability back in september, I found an interesting issue.
All ZERT members tried to get as many as possible VGX.DLL file versions (the affected DLL) from different Windows versions, so eventually I could write a generic binary signature (which will find the vulnerability point and later on patch it).

My signature worked for all DLLs I had, approximately 20 files. It didn’t work on 2 different DLLs for IE 7, which were pre-patched from June already (according to the compilation time, that is we assume the build machine is accurate).
You can read about it at: http://www.secureworks.com/researchcenter/weblog.html, a blog post “Zero Daze” written by Joe Stewart, also a member of ZERT.

There was only one DLL from IE5, that my signature didn’t “catch”. Back then, when I was writing the patcher, I didn’t have all DLLs in existence (this is the reason why I made it a generic signature). Some of them I got later, and my generic signature still worked well. Eventually, I realized that this DLL was already pre-patched.

Speaking technically: It had a size test in the beginning of the function. It checked whether the input buffer (fill method) isn’t longer than 0×100 bytes, if so it returned null. So in contrast with IE7 pre-patched DLLs, MS lets the fill method buffer be copied to the destination buffer (on stack), but stopped at 0xfe WCHARs. Same was done for the patched DLLs, which as you can see, is more permissive than that IE5 pre-patch.
Examining the compilation date of that IE5 file (specifically version:5.0.3014.1003) results in timestamp of Nov 30, 1999. Which makes sense, since IE5 came out when Win2000 came out too, take or give.

After all, it is clear that some source code was thrown out from the repository. The reasons behind I can’t tell, but it’s a solid proof that we were secure for a short period 7 years ago!
More than that, can researchers find vulnerabilities by going over on older versions of Windows’ DLLs to track bugs? (ala bindiff) you bet.
So what do you think really happened?

Enjoy the weekend,
Gil Dabah

Share
  • mxatone

    That’s really interesting. Thanks to share this anecdote with us.

  • http://blogs.securiteam.com/index.php/archives/author/thor Thor Larholm

    Some Microsoft developer originally wrote that function so it would malfunction appropriately if it received inappropriate input – in this case, by returning null instead of just stuffing the buffer with the first 0xfe or 0×100 chars.

    The most likely explanation for what then happened is that some unrelated software malfunctioned because it did not properly handle a null return value and relied on the buffer still being filled with at least some bytes. At this point the original developer was probably working on something else, and the new QA developer in charge of fixing this “compatibility issue” noticed – and removed – both the size check and the null return value.

    The unrelated software now worked as expected and people moved on.

    What I would really like to know, is why none of the automated static source code checkers discovered this vulnerability long ago. Since this vulnerability was fixed in June for IE7 and only later discovered in the wild, it’s obviously been leaked somewhere along the chain of command/communication.

  • Share







  • Categories


Security RSS Subscribe