Subscribe to
NSLog(); Header Image

Another Day, Another Hole in IIS

The Insecure Invasion Server has been riddled with another round of bullet holes. How sick are you of buffer overflows? How much sense would it take to, I dunno, code in checks for these things? Jeez.

4 Responses to "Another Day, Another Hole in IIS"

  1. Funny you should mention that--I'm actually on a quest at work right now to end our use of IIS once and for all (we have a legacy web app that uses ASP, but I'm fighting tooth and nail to replace it with Java and Tomcat). I love seeing stuff like this--it just gives me that much more ammo!

  2. BugTraq Search: Buffer Overflow

    Matching Results: 3685

    Not so easy, it would appear.

    I'm not saying this makes it OK ... definitely sucks and I wish as much as anyone that we would clean these things up faster.

    But come on, I suspect you're a better developer than to expect that purging all your bugs is as easy as snapping your fingers.


  3. I am. But buffer overflows are soooo common that, well, people should be extra careful to look out for them specifically.

  4. For what it's worth, Microsoft has far better static code analysis tools than I've seen at any other company or for any other operating system. They have some terrific tools for checking for buffer overflows and just about any other related problem, and they use them on all new products. If everyone else did the same, you'd find far fewer bugs (to say nothing of security holes) in Linux, Mac OS X, and other operating systems.

    This hole doesn't even affect the latest version of IIS. Apple, Red Hat, and others are lucky that there aren't many people poring through older versions of their software looking for security holes.