Windows .ANI Problem Surfaced Two Years Ago

An anonymous reader writes "There's a new twist to the tale of Windows .ANI exploit, that's been in the news all week (including when a spam campaign used the teaser of nude Britney Spears pictures to lure people to malicious sites). InformationWeek reports the Windows .ANI bug at issue first surfaced — and was patched — two years ago, in early 2005. 'If they had simply looked for other references for the same piece of code when they originally dealt with it a few years ago, they would have found this and patched it in 2005,' says Craig Schmugar of McAfee. 'It would have saved a whole lot of people a lot of time, money and effort.' Microsoft claims this .ANI vulnerability is different from the old, but beyond that they're not talking."

Re:Incompetent Liars

[garobat]

On top of all of that, this is yet another (of about three instances I have found so far), where it's clear that Vista is not "all new code" as MS likes to maintain it is. It seems like this bug occurred because the same old *.ani code from the previous versions of MS Windows was included in Vista with literally no oversight and no checking.

Well, considering the mount of dialog boxes kept unchanged from XP and all, it seems pretty obvious that Vista is not "all new code". And what would be the point, as long as core component are rewritten, why would they redo the whole gui code?

Re:Incompetent Liars

[UnknowingFool]

This sounds familiar. One of my friends who once worked for MS showed me a bug in the screen saver. It was first identified in NT4. It was fixed in Win2K. But when XP came out, the bug was back. It wasn't one that would allow for attack; it was just one of those annoying ones, but it was astonishing that it still existed.

Re:Incompetent Liars

[Foolhardy]

There is a certain class of security vulnerability where malformed data passed to a library in the same process can cause code execution. From the library's point of view, since the library is in the same process as the caller, they're both at the same trust level, so calling a function does not cross a security boundary and no secure validity checking need be performed. The worst that could happen is that an app causes a library to execute code in its own process, a non-issue. The only parties involved are the application and the user library. This was the picture in 1993 when the first version of Windows NT (3.1) was released. It was largely still the case in 1995 with the release of Windows 95. This is the era where this and other vulns (like the GDI metafile escape one) are from.

Problems start when the app passes along data from some outside untrusted source without understanding its content or validating it, like when a web browser passes an .ANI to user32.dll. Back when user32.dll was written for NT 3.1, the devs never conceived of an app implicitly loading a malicious .ANI (without validating it) from a third party. At the same time, the app would much rather treat those things as opaque blobs to pass on to libraries, implicitly expecting them to do the validation too. The libraries see the security boundary as being on the other side of the application, expecting the application to validate any data before processing. Both expect the other to validate data, but in some cases (like this one), neither do.

Right now, the trust assumption of many user libraries hasn't been fixed because there is a lot of code in that position and it would be a lot of work to go through it all. Managers hate fixing code issues like that because it takes a lot of time and money but doesn't result in anything tangible like pretty features. Applications already suffer enough code bloat without having to implement validation for all the data they come in contact with that gets passed right to support libraries-- managers don't want to spend time and money on validating things that should be someone else's responsibility. Microsoft has had this class of vulnerability on low priority for a long time, and it's been the source of A LOT of issues.

I'm not excusing Microsoft's behavior, just trying to explain it somewhat. Someone sure dropped the ball in not finding finding problems similar to the 2005 issue though.

This by reason of Microsoft's own self-stated bug hunting and code modification procedures.

Microsoft is a big company. Not every department is following the Security Development Lifecycle, as much as marketing may like to imply it. The main two examples that do are SQL Server 2005 and IIS6, both of which are doing very well. I haven't heard Microsoft say that all of Windows or the Win32-GUI core team were using SDL.

On top of all of that, this is yet another (of about three instances I have found so far), where it's clear that Vista is not "all new code" as MS likes to maintain it is.

Vista contains copious amounts of new code, but very little of it replaced old code. The sound system (the mixer mainly) was largely rewritten, the backup program got replaced with a POS from scratch, the logon GUI arch (i.e. msgina.dll replacements) got replaced... and I can't think of anything else that is new code to replace old code. I'd say that at least 75% of the Windows NT3.1 code base is still present in Vista.

Re:It would be nice to have real information on th

[mgiuca]

Basically, an animated cursor is just one way to exploit a problem with Windows' GDI (graphical device interface) implementation. Windows runs this as part of the user's session and it is, in part, in kernel mode.

This is why I've been saying this problem has NOT been caused by a mere "bug in the code". Bugs happen to everyone, and it's not about blaming people. It's an accident.

But this issue has not been caused by a mere bug. It's been caused by a catastrophic design flaw in Windows itself (which I personally believe is a side-effect of Microsoft's marketing strategy) - and that is that EVERYTHING is in the kernel. In UNIXes, the GUI is nowhere near the kernel. There is no hope in hell in a UNIX environment of a mouse cursor taking control of your computer. This is caused by the fact that the GUI in windows runs partly in kernel mode. It's the architecture's fault.

If you ask me, this goes right down to the name of the OS - "Windows". It says it all. "This operating system is based on the GUI". And it literally is. The side-effect is that the GUI itself (the windows) can attack your computer.