Slashdot Log In
MS Mulling Changes to Thwart .ANI-type Attacks
Posted by
Zonk
on Fri Apr 27, 2007 03:17 PM
from the thinking-around-the-problem dept.
from the thinking-around-the-problem dept.
Scada Moosh writes "ZDNet has a story about the lessons Microsoft learned from the recent animated cursor (.ani) attacks and some of the broad changes being made to flag this type of vulnerability ahead of time. The changes include a possible addition to the list of banned API function calls, more aggressive checks for buffer overruns and enhancements to existing fuzz testing tools. '[Michael] Howard said Microsoft will "rethink the heuristics" used by the /GS compiler to flag certain issues. "Changing the compiler is a long-term task. In the short-term, we have a new compiler pragma that forces the compiler to be much more aggressive, and we will start using this pragma on new code," he added. Two other Windows Vista security mechanisms -- ASLR and SafeSEH -- were also in place to catch code failures but, in the case of the .ani bug, Howard said the attackers were able to wrap vulnerable code in an exception handler to find ways around those mitigations.'"
Related Stories
[+]
Technology: Windows .ANI Problem Surfaced Two Years Ago 110 comments
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
What is a banned API call? (Score:5, Interesting)
Re: (Score:2)
Re:What is a banned API call? (Score:4, Informative)
It's all kinds of sexy... but basically, it removes functions in which programmers have frequently used incorrect or for which there is no absolutely correct way to use them and still validate user supplied data.
Parent
Re: (Score:3, Informative)
Microsoft's build tools will treat any calls to banned APIs [microsoft.com] as errors. They aren't removed from the system because they are used by many existing applications. For example, both strcpy and strncpy are banned at Microsoft. Yet many people have been using strncpy as a replacement for strcpy, so it needs to b
Re: (Score:3, Funny)
If only Microsoft would add a C++lippy to MSVC to clear up these kinds of things.
Default deny policy (Score:3, Insightful)
While risking being out of sync with Slashdot's schizophrenic stance on Microsoft-bashing, let me lower my hammer on this one:
"The changes include a possible addition to the list of banned API function calls"
That's exactly the problem with security under Windows! (okay, there are other problems as well)
Microsoft needs to apply a "default deny" policy to all aspects of Windows' security and this sort of thing wouldn't be a problem in the first place. There shouldn't be a list of BANNED calls, there should be a list of safe ALLOWED calls.
I'm not saying that other operating systems couldn't do a better job too, but security is one (huge) area where Microsoft really and truly sucks - and it isn't something they can solve overnight, either. It seems ingrained in their philosophy and permeates all aspects of Windows (and other products).
Re: (Score:2)
Unfortunately for Microsoft, they have a hell of a lot of that sort of code in Windows and a lot of their products. The ones they've really re-engineered like IIS6 or written fro
Re: (Score:2)
There shouldn't be a list of BANNED calls, there should be a list of safe ALLOWED calls.
I think this is similar to the GCC concept of hiding symbols. The only real issue is when compiling legacy code which links directly to those hidden symbols, linking will fail. Obviously, that's the point. I think, then, that the Microsoft approach is lazy: they're more worried about "legitimate" legacy code no longer working well with later compilers than they are about actually hiding the offending API calls from userspace all together.
Re: (Score:2)
It's the PC heritage, going back to the days when no-one in the non-Unix PC world gave the slightest thought to security, because you could get away with it back then. It's a difficult mindset to change, beca
Related news (Score:5, Funny)
In context (Score:2)
Incremental approach. (Score:4, Insightful)
This incremental approach will eventually result in operating systems that are secure to all but the most sophisticated local attacks. You can't stop the attack where someone just downloads something and blindly runs it. Unlike most people, I don't think computer OS's and apps will always be as insecure as they have been for the last 15 years since the explosion of the Internet to the masses.
It may take another 5 years, but I think we're getting there. Vista isn't perfect, but it's a step closer.
For starters.... (Score:3, Insightful)
Wait, sounds familiar (Score:2)
You know if Bill Gates was any kind of leader, he would call for his programmers to scrutinize their code for these kinds of security issues. Oh wait! He did 5 years ago. [usatoday.com] It's great to know that MS has spent the last 5 years innovating such features.
Use non-overflowing buffers, heaps etc. (Score:2)
In this day and age of OOP and libraries, there's no excuse but negligence for crappy code.
Windows - be careful! (Score:3, Funny)
What Microsoft REALLY Needs To Do... (Score:3, Insightful)
Microsoft made a big to-do about "focusing on security" in the development of Windows Vista, but instead spent all this time A) spackling over the screwball security holes that the superfluous bits of the last version of the operating system created, and B) bolting on more superfluous bullshit.
The pattern of flagrant Windows/Microsoft security breaches has traditionally involved the fracal-like fuzz of superfluous features surrounding Windows. It simply tries to be too much. How many times have we heard about some hole in Internet Explorer that lets l33t h4xx0rs walk in and screw with your OS? Animated cursors opening security holes. ET-phone-home Windows Media player opening security holes. IIS subsystems on home user's computers opening security holes... Ad infinitum.
You want a web browser on your PC? Install a web browser. It shouldn't be your OS'es job. You want animated cursors? Install a cursor manager. It shouldn't be the OS'es job. You want media players? Install a media player. It shouldn't be the OS'es job. Are we seeing the fucking pattern here, yet? If Microsoft could focus on the core of the operating system, making it the platform and the framework that the rest of your computing experience happens on instead of trying to make it the damn "multimedia/computing experience" itself I'll wager a significant portion of these stupid, smack-on-the-forehead sort of problems would go away. And if and when they did crop up, users affected could just patch or uninstall the affected browser/media player/cursor manager/whatever instead of having it permanently tied into their OS for the rest of time (heaven forbid, for example, users reinstalling Windows into it's stock, unpatched state).
Innaccurate Summary (Score:3, Insightful)
Howard said that the vulnerable code happened to be wrapped in a very general try/catch block.
This try/catch block, which was in the vulnerable code already, and not injected by the attackers, potentially allowed the attackers to repeatedly try different memory locations looking for system call addresses that were randomized by ASLR.
Without this try/catch, the process would have crashed after the first failed attempt.
In other words, liberal try/catch policies can potentially expose security vulnerabilities by giving bad guys more than one chance to do their bad deeds.
Also, there were no reported instances of Vista being compromised. It is doubtful that the engineers of the various exploits targeted Vista, and therefor didn't take advantage of the try/catch issue to overcome ASLR since XP doesn't have ASLR. In addition, Protected Mode IE would have thwarted the attack even if they had.
But I Thought... (Score:3, Interesting)
So what did they do here? Rewrite the .ANI handler by re-implementing the same bug as before?
Or were we just lied to again, by Microsoft?
Re:But I Thought... (Score:5, Informative)
I guess it's easy to be mad at Microsoft for lying when you put those lies in their mouth yourself.
Parent
Re: (Score:3, Informative)
Re:When have they stopped saying that kind of thin (Score:3, Insightful)
NT 3.0 was written from scratch. Please provide proof to the contrary, if you have it. Then, provide proof that *Microsoft* has claimed Vista is rewritten from scratch. And I said Vista, not Longhorn or anything else.
I'd calculate that about the same number of times you've declared "M$ Winblows" was "dead".
But I could be wrong.
Please provide proo
Re: (Score:3, Informative)
Many of the compatibility problems are related to fixing bugs in the OS. Any time you change the behavior of the operating system you risk breaking some piece of code that relied on the old behavior. Notice tha
Security broke dragging files to cmd.exe (Score:5, Interesting)
In NT, console windows are actually owned by the most privileged user-mode process in the system, csrss.exe. One of Vista's big security changes is that processes cannot send window messages to windows owned by processes of higher security clearance. This means that Explorer cannot send a message to console windows telling them that there is a file being dragged to it. Starting Explorer as Administrator does not help, because csrss.exe runs with higher privilege than that.
Rather than fix the insane design issue of csrss.exe owning console windows, they decided to leave it the way it is. Never mind that there have been exploits against csrss.exe through the console system in the past.
To give you an idea of how bad of a hack the console implementation is, kernel32.dll's WriteFile detects console handles, which are fake handles, and translates the call into an RPC call to csrss.exe. This breaks all kinds of stuff.
Re:Maybe... (Score:4, Funny)
Parent