Slashdot Mirror
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."
when a spam campaign used the teaser of nude Britney Spears pictures to lure people to malicious sites
Talk about an anti-virus.
If all attempts to hijack my machine involved using her as a lure, I'd uninstall AVP in a heartbeat; you couldn't pay me to see her nude.
The last time I saw an ANSI bug was during my days as a BBS Sysop years ago!
So now we can say that Windows actually had twice as many ANI bugs as we originally thought and Microsoft admitted so themselves.
an .ANL exploit?
'Loose' is when your pants are three sizes too big. 'Lose' is when you misuse 'loose'.
This has been written about multiple times in multiple places. Not to mention this was already referenced in the article from the Slashdot posting a few days ago. Keep it moving...
Of course this
Steve, leave the slashdot editors alone. If you need to blow off steam, go throw a chair or something.
Help stamp out iliturcy.
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?
remember winnuke? same shyte, different day. http://www.unixgeeks.org/security/newbie/security/ winnuke.html
How many other people clicked on the "teaser of nude Britney Spears pictures" link in the Slashdot story and were bitterly disappointed?
Hello, Mr. Potato Head! Back doors are not secrets!
Don't blame me, I voted for Baltar.
Denial about an unfixed security problem? Time for the "insecurity" tag.
Cwm, fjord-bank glyphs vext quiz
I wonder how many coders actually read slashdot.
I can see two seperate bugs causing the same result, I've dealt with it tons of times.
"the bug is back, you didn't fix it"
and I say, "no this one is different"
Meh
Who really fucking cares?
I don't need no instructions to know how to rock!!!!
this is useless without pictures
find / -name "*.sig" | xargs rm
Does anyone have a link to any information that actually explains how thi exploit works? I've been reading about it for over a week, but can't find any susbtantial information Just warning that it can hit you from web page content or html e-mail reading. But what that has to do with animated cursors is not at all clear. I've never yet seen an html page that could change my user selected cursor, so how is it that this exploit actually affects the user's computer?
I'm an American. I love this country and the freedoms that we used to have.
thats right the website was hacked the other day and the .ANI exploit was stuck in theree ksitehack_1.html
http://www.infoworld.com/article/07/04/06/HNasust
Although I never visited the site because it was slow to begin with and had the worst download rates.
Netcraft says for the asus.com website that it was running Windows Server 2003 but other foregin ASUS sites were running a mix of Linux/BSD.
Does anyone have a link to any information that actually explains how thi exploit works?
Here you go: Analysis of ANI "anih" Header Stack Overflow Vulnerability
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. Just like Jon Ellch and David Maynor showed with the Apple wireless driver exploit, if you can get access to the kernel, you can do pretty much anything you want. Any code you run will no longer be limited to the permissions of your user account.
J Wolfgang Goerlich
http://www.securiteam.com/windowsntfocus/5XP0515L5 W.html
This is Slashdot! Dupes abound, stories recycled, and anonymous cowards nitpick!
Thanks. This was very helpful, and also makes it very clear that this is much more serous than something that just deals with animated cursors. In fact, I'm at a loss to understand why the community is attaching the aminated cursor reference to it.
I'm an American. I love this country and the freedoms that we used to have.
Interesting, thanks. Or not that interesting - just another buffer overflow exploit in code that doesn't validate it's input fully.
Observations: If DEP/the NX/XD bit was actually turned on on Vista or XP by default, this would have no effect.
Bit dissappointing that Firefox falls for this too. I REALLY DON'T WANT Firefox to support animated cursors....
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
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.
If DEP/the NX/XD bit was actually turned on on Vista or XP by default, this would have no effect.
Would it? I am not so sure. DEP protects against execution from the stack. Instead, this exploit uses jmp (jump) to make calls against user32.dll. This is a different animal than what DEP is designed to catch.
J Wolfgang Goerlich
The analysis you link to does not mention the kernel. It's true that some GDI is in kernel land, but a surprising amount of resource access, like this, is not. The exploit, in its current form, is firmly in the userland part, and constrained by the security tokens of the thread and process. That's often bad enough, though.
nice work finding that, thanks.
You know, if Microsoft can pay a dozen people to make sure a reporter writes THEIR story and not his/her own, you'd think they'd be paying developers enough and putting enough "process" in place in order to make the product better. But here in 2007, it sure looks like they still suck at software engineering.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Not quite.
It kind of depends on your definition of "taking control of your computer". If you mean that exploiting a cursor library alone won't let you gain root, that is true as libraries don't run with that sort of privilege. However, if you were to define "control of your computer" as being able to delete all your data, set up a spambox or an irc/web/ftp server on your machine and so on, well that's quite possible, given that these libraries run with user privileges.
The problem is that, in practical terms, those two "levels of exploitation" are indistinguishable. Once an attacker possesses user privileges on your machine, she is then free to find and use exploits that would give her root on your box, upon which you're just as owned.
While the moral victory is nice, in that we UNIXy types don't worry as much, it's all irrelevant as in both cases the only really safe thing to do is wipe the machine clean and start fresh.
"DUR!!! A FILE COULD NEVER BE MALFORMED SO THIS CODE CAN'T LOSE!!!"
You've rather eloquently stated the reason why average programmers shouldn't be allowed to code security-sensitive code in the C family of languages.
Everybody gets this wrong. The argument is always for performance. Well, a Windows machines overridden by spyware is just as slow as if the whole userland were written in c#, so I'm not buying that one. "Not even Microsoft" can get security right in C++. The quotes are there not because I expect them to, but rather because of everybody they have the financial resources to do it right. Everybody else has fewer financial resources. If Microsoft can't afford it, nobody can.
Seriously, give the high-performance stuff to somebody who is really skilled and knowledgeable about security, cross-check it 10 times, and let the interns play with rounded-end languages. Everything else is a band-aid.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Do you mean that an exploit to give full user powers is not practically very different from an exploit to give full root powers? Well yes and no.
On my machine (I am the only user), you're right. Anything getting full user powers could run servers, access/modify/delete all my documents and so on. To fix it, yeah I'd have to wipe my user and start again. But I'd only have to wipe my user. I wouldn't have to reinstall all my apps and reconfigure the machine.
And your second point is that they could find an exploit to get root (since my user has sudo powers, granted you need a password but yes, a possibility). So... I haven't heard of such an exploit (besides a "social engineering" exploit where the user actually did type the password and then ran a malicious script).
So yes, not total security, but it provides a layer of protection.
However, the big advantage of the root/normal user distinction is on the platform UNIX was designed for - a multi-user system. In a true multi-user system, most users have absolutely no capability to run with sudo powers. I'm quite confident that ANY malicious threat could at very worst completely destroy a single user account. The way unix is designed, it couldn't affect any other users, or root, and it couldn't get root powers since the user account it's running on doesn't have root powers either.
I was thinking specifically about rootkits. My point is that while in theory that's how it works (normal users don't have root priviliges, end of story) the reality of things is a bit different. In most cases, if not the absolute majority, it's perfectly okay to wipe your user account and make a new one.
However, if it's security you have in mind, you have *no* guarantees whatsoever that your machine isn't rooted, unless you painfully run a hash check against every system binary and recompile your kernel from fresh sources. Until you do that, as far as you know whoever took over your user account also got around to rooting your machine. The least painful way to be absolutely sure is to start afresh with a new system.
Maybe I'm just paranoid, but I like to be absolutely certain whenever possible.
Does this also mean if you can't trust your own users, they could be using root as well?
I understand that any one hole in a system means people can flow through. But I thought the point was that the ENTIRE system was designed from the ground up with this in mind, so that there are literally very few places to poke holes in (and those places are highly checked for security).
Hm. I'd prefer "evolved" over "designed". My understanding is that what we currently know as Unix has come about through normal trial and error over the past thirty years.
As far as I know, as I'm no researcher in the field, security is a bit of a state of mind. It's mostly a measurement of how much time and effort/money you're willing to invest in it; you can code for it in your specs, but it'll depend on how much time you put into debugging it (which, in turn, has diminuishing returns as time wears on: you don't know how many bugs you have at the start and it takes too long to test a comprehensive list of situations). Not to mention the law of unintended consequences, where a bug in an underlying system (which could be anything from your compiler to your processor architecture) exposes something that you didn't want exposed.
So, it all depends on what you mean by security. It's very hard if not impossible to guarantee that your system is attack-proof, 100% of the time. However, 99% or 95% is a lot easier, in comparison, and for most cases, iunno, 80% is good enough. If your system can only be broken by the top 20% of attackers, the likelihood of anyone of them visiting your specific system may be too low to be worth investing your time and effort in (case in point: your average blog).
As such, if you're shooting for the top percentile, I guess that does mean you can't trust your users. You have a whitelist of programs for your users, you routinely inspect logs and the second you realise something was compromised, you wipe it clean and restore it from backups - after figuring out how to prevent the same thing fom happening again.
Effectively, this also means that you can't really just point at a system and declare it more secure. The unix security model happens to be less permissive than the single-user model windows evolved around, and over time was developed with the explicit knowledge that several people you might not trust will be using it. The NSA pointed out that it's still not that great, and gave us in turn SE Linux modules.
Even the darling of OSS security, OpenBSD, can only do what they do because they consider it their utmost priority: they openly sacrifice portability and system speed and efficiency because, in their routine code audits (which no one else bothers or can afford to do) they optimise for security.
This is all sounding good (you seem to be quite an expert). So I'll just say: yes - but the system architecture does have a lot to do with the security model. It doesn't mean it's perfect, but IMHO, the Unix security model is far superior as an architecture than the Windows one, and that says something.