Why Blaster did not infect Windows Server 2003

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 http://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 (10)
  1. Ilya says:

    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?

  2. 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!

  3. 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!

  4. oh.. sorry for double posting :/

  5. MIchael Howard says:

    My bad – thanks!

  6. Michael says:

    Ilya – Home and Pro aren’t separate compiles. They’re built from the same source code, and each binary in Home is identical to the binary in Pro. There may be some exceptions, but I don’t know of any off the top of my head.

    This makes development and serviceability easier. Imagine if each patch had to have a separate pro and home version.

  7. Ilya says:

    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?

  8. MIchael Howard says:

    >>it is not authentic

    Windows File Protection 🙂

  9. Ilya says:

    But how? 🙂 The DLL is not ships "in the box" with operating system because there is no EFS support in Home. It is not a system file anymore, but from the other hand the Home’s binaries (identical to Pro’s) are up to it.

Comments are closed.

Skip to main content