Microsoft is not alone when it comes to writing vulnerable code. It’s downright hard to write secure code in low-level languages. It’s understandable, especially when most of your core code was written before buffer overflow exploits were even understood by most programmers.  But when a vulnerability is pointed out in your code, and you claim to spend inordinate amounts of time developing and testing patches for it, wouldn’t it make sense to spend a little time auditing the rest of the code for the same bug?

I’m talking about the new zero-day bug found in Windows (all versions, even Vista) that allows an attacker to gain control of fully-patched machines through the use of a malicious animated cursor file. Sounds vaguely familiar, doesn’t it? Well, it should - back in 2005, eEye reported such a bug to Microsoft. Apparently, some code in user32.dll would read the “anih” header of a .ANI file into a static buffer when loading an animated cursor. Nothing wrong with that - except they took the length of memory to copy into the buffer from a value provided in the header itself. This is the most common vulnerability found in binary file format parsers - they trust the file format to tell them how much memory can be written to.

Microsoft closed this hole with the MS05-002 patch - or so we all thought! Turns out Microsoft overlooked some nearby code which does the exact same copy operation from the “anih” header. So, some two years later, we have a zero-day exploit on our hands - all the attackers had to do was figure out how to format the .ANI file to reach this second bit of code. At this point, with no patch in sight from Microsoft, a thorough code audit could have saved a lot of frustrated Windows administrators and end users a lot of headache this month.

This entry was posted on Friday, March 30th, 2007 at 1:43 pm.

Share This Information | QA, Anyone? SlashDot | del.ico.us | Digg it | Technorati | Reddit

Other SecureWorks Blog Categories: General (20) Links (7) Phishing (1) Research (60) Spam (1) Trojans (4)