Partager via

Why Blaster did not infect Windows Server 2003

  • Article

I've been meaning to write about this for some time, but while pondering over my very dead laptop (it won't even get to the “Choose an OS to boot' option”, I remembered.

The code which Blaster took advantage of was in the released version of Windows 2003 :( but the worm itself did not infect Windows Server 2003 machines, here's why: the /GS flag. The buffer-overrun was detected by the -GS handling code, which caused the OS to shut the RCPSS process down. Sure, not a good thing - but a heck of a lot better than being infected by the worm. You can read more about /GS in Brandon Bray's blog https://blogs.msdn.com/branbray/archive/2003/11/11/51012.aspx.

In case you're not aware, Windows XP SP2 is also compiled with the latest 'n' greatest version of /GS.

Another cool thing in Whidbey is /GS is implicit; if you compile code using this:

cl -c mycode.cpp

You get the -GS stack-overrun detection code by default :))

If you don't want this option (why don't you want it?), then you must compile with /GS-

Comments

  • Anonymous
    May 23, 2004
    Btw about OS compilation (not relevant to Blaster issue actually): why XP Home tries to load non-existent EFSADU.DLL in each process it starts? Why Home is not properly recompiled to dropp off unsupported features from XP Pro?
  • Anonymous
    May 23, 2004
    Hm.. in "You get the -GS stack-overrun detection code by default :(" did you mean to have ":)" at the end instead? ;) seems like a good thing IMO!
  • Anonymous
    May 23, 2004
    Hm.. in "You get the -GS stack-overrun detection code by default :(", did you mean to have ":)" at the end instead? ;)

    IMO this seems like a good thing!
  • Anonymous
    May 23, 2004
    oh.. sorry for double posting :/
  • Anonymous
    May 23, 2004
    My bad - thanks!
  • Anonymous
    May 24, 2004
    The comment has been removed
  • Anonymous
    May 24, 2004
    Easier indeed. But from the other hand it is also implies potential issues (take a look at example above: what if there is such DLL and it is not authentic?) Does such implications simply considered as acceptable risk?
  • Anonymous
    May 25, 2004
    >>it is not authentic
    Windows File Protection :)
  • Anonymous
    May 25, 2004
    The comment has been removed