Slashdot Mirror
MS Mulling Changes to Thwart .ANI-type Attacks
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.'"
Take a gander at Microsoft's list. If the Safe options are on, the API is not available.
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.
A banned API is one that is likely to cause security vulnerabilities. There are replacements for most of them that are less likely to have problems, but they aren't part of the official C standard library.
Microsoft's build tools will treat any calls to banned APIs 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 be in the CRT library.
When did Microsoft ever claim to have rewritten Windows from scratch?
I guess it's easy to be mad at Microsoft for lying when you put those lies in their mouth yourself.
It was delayed largely because they reset the project in late 2004. The original Longhorn was based off of the XP codebase. When they reset development they started from the Windows 2003 codebase (which was based off of the XP codebase). At no point did they claim that they were starting from scratch.
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 that they fixed all of the known security bugs in XP, even though they haven't released patches for XP. With Vista, they can break compatibility to fix security flaws. Breaking apps that currently work on XP would cause major problems for companies.
Comment removed based on user account deletion