Slashdot Mirror

← Back to Stories (view on slashdot.org)

MS Mulling Changes to Thwart .ANI-type Attacks

Posted by Zonk on 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.'"

4 of 99 comments (clear)

  1. What is a banned API call? by solafide · · Score: 4, Interesting

    Does the banning of an API call mean that the call is still there, it just can't be officially used? Couldn't it still be used deviously to exploit it? Shouldn't we just remove the function from the API, not prevent the compiler from compiling code with that function being used?

  2. But I Thought... by Nom+du+Keyboard · · Score: 2, Interesting
    Wasn't Vista rewritten from scratch, rather than using the old NT code base? Isn't this wh it took an extra 3 years to arrive? Isn't this where there are still major compatibility errors in Vista compared to previous NT and Win95/98/ME versions?

    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?

    --
    "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
  3. Security broke dragging files to cmd.exe by Myria · · Score: 5, Interesting

    Prior to Vista, you could drag files from Explorer to cmd.exe to have it type in the filename for you, exactly like on Mac. However, due to overzealous security changes by Microsoft, this does not work in Vista.

    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.

    --
    "Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
  4. backwards by midnighttoadstool · · Score: 2, Interesting
    Here we go again.

    Another pointless discussion that doesn't acknowledge the depth of complexity of backwards compatability, and its commercial necessity.