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."

Comments

Incompetent Liars

[Jeremy_Bee]

The thing that bugs me the most about these kinds of issues is the reporting of them in the media.

If you read the slashdot summary (or even the whole first page of the article), you get the impression that some people think the bug is pretty much the same thing as the 2005 one and that Microsoft disagrees. The story is structured like a "He said, she said," kind of thing and no one is painted as right or wrong. If you *do* manage to make it to the second page of the article however, you find out that several very respected security professionals and security companies present detailed compelling evidence to the effect that Microsoft is both incompetent and disingenuous in their opinion on this bug.

It is the same bug (essentially) reported in 2005, and it should have been caught in a matter of hours or even minutes after the 2005 bug was initially reported to them. This by reason of Microsoft's own self-stated bug hunting and code modification procedures.

The conclusion is absolutely inescapable that Microsoft completely failed to follow their own basic rules of coding and security auditing here. They also are lying or at the very least splitting hairs about it being a "separate issue," and they seem to be deliberately trying to pull the wool over peoples eyes about it. Yet this story has been reported around the web as a kind of "maybe McAfee is right, or maybe Microsoft is right," thing for the most part??? Why?

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.

Why do people buy products from these people again?
And why do they always seem get the benefit of the doubt in the media?

Re:Incompetent Liars

[Watson Ladd]

To answer the first question: API lock-in. A lot of strange hardware is windows-only, and the same with a lot of software. Microsoft might have horrible API's, but people use them to appeal to the Windows market, and so increase its size. Look at COM vs. Objective-C. The answer to the second question is because of the fear of a libel suit. You said the bug occurred because Microsoft didn't check it. Far more likely is they checked it incompetently. The difference is the difference between libel and truth. Actually, I might still be vulnerable to a lawsuit.

Re:Incompetent Liars

[bendodge]

Why do people buy products from these people again? Because (overall) it just works, and has incredibly good hardware support.

It also is aesthetically pleasing. While there has been lots of effort put into making things like KDE look good, the individual shiny buttons and bars don't agree with a universal theme. Windows development is centralized, so the everything fits together visually.

I personally prefer the look of Windows XP to any OS (note I haven't used Vista), just because the gradients, buttons, and esp the fonts all fit together smoothly.

Re:Incompetent Liars

[ceroklis]

Microsoft has access to the source code, the "experts" don't. They have simply no basis for these claims. Their conclusions are based on their ideas on how code is supposed to be written, not on knowledge of the actual structure of the code in question. Ever tried to debug old spaghetti code that was written ten years ago, never properly documented and that nobody in the organization understand anymore? Maybe it is more complicated than they think. That's why I wouldn't trust them more than Microsoft on these matter. Not that I would trust Microsoft in the first place, since they have to interest in being open and honest on these matters, but that's ok.

As an aside, I am tired of these endless criticisms of windows. It was never marketed as an über-secure or über-robust system. So stop complaining and understand that it is a relatively inexpensive and user-friendly OS, with a good feature set, an enormous library of software, good backward compatibility and only limited work being done on its security or robustness. If the good points matter more to you than the bad ones, use it and learn to live with the occasional exploit. If you want robustness and security, put your money where you mouth is and use Trusted Solaris. But don't complain if it is expensive and has no games.

Re:Incompetent Liars

[Tanuki64]

Do you write code? It sounds like some copy-and-paste code had a bug in it, and they didn't catch both places.

I do write code. And copy-and-paste code is always a sure sign of an incompetent coder.

Re:Incompetent Liars

[Bodrius]

Really? I write code for a living too, and a categorical statement of the form "doing X is ALWAYS a sign of an incompetent coder"... always seems to me, at best, a sign of an unexperienced coder. Either that, or an extremely lucky one.

I'll just assume your case is the latter :-)

Sure, copy-and-paste duplication should be avoided where possible, along with gotos, reinventing the wheel, long complicated functions, lack of type safety, etc.
Also, all code should really be a perfect and pristine example of elegance and modularity. Bug-free is even better!

Reality bites, though.

Unless we're talking of brand-new projects of a small size, I find it really hard to believe that comminiting to 0% copy-and-paste-code is a practical proposition.

For a non-trivial product with some legacy, copy-and-paste is often the best among various non-optimal choices.

- Do you really want to tightly couple these two unrelated components because you want to use those 5 lines of code?
- Can you afford to carry over all of the dependencies on that library or class?
- Or can you afford the refactoring to avoid those dependencies? How many new components (which were not changing before) do you need to retest now that you pulled the code out?
- Can you afford to lose that development and testing time on other features that you need for RTM?

    That's not to mention the almost-guaranteed design time discussing where that re-usable code should move to in the first place... and do we need to change it to make it more generic? Do we need to ship all the refactored components with no functionality change? etc. etc.

I agree with the sentiment: Copy-and-paste duplication sucks, and should be avoided wherever possible.

But honestly, if you can ALWAYS say that avoiding copy-and-paste at all costs is the right decision for your product, for your team, and for yourself... I don't know whether to envy you, or to fear you.

useless

[digital bath]

this is useless without pictures