Slashdot Mirror


WebDAV Buffer Overflow Attack Compromises IIS 5.0

rf0 writes "Well CERT is reporting a new overflow attack for IIS 5.0. Microsoft has released a bulletin. Better download those patches and fix another security hole." According to this CNET story, Microsoft says that this is already being exploited, at the very least since last Wednesday.

10 of 367 comments (clear)

  1. Again... by Anonymous Coward · · Score: 3, Interesting

    A buffer overflow allowing an entire system takeover... Why is the code that the web server has access to change allowed to take over the system?

  2. I am kind of impressed by obotics · · Score: 5, Interesting
    Wow! Microsoft already has a patch released? Not bad at all!

    Well, if they are going to have bugs, it is not that bad of a thing as long as they are patched promptly. Then again, many admins do have a tendancy to run unpatched machines.

    1. Re:I am kind of impressed by RLiegh · · Score: 3, Interesting

      Well, if they are going to have bugs, it is not that bad of a thing as long as they are patched promptly. Then again, many admins do have a tendancy to run unpatched machines.

      Many of these unpatched boxes are even windows machines. ;)
      (No, I'm not slamming windows, or *n?x; but bad admin practices.)
  3. A quite-interesting report on MSNBC by expro · · Score: 4, Interesting

    It seems quite likely to me that that was an under-reported version of this incident reported on MSNBC, that permitted an intruder with apparent quite-hostile intent onto US Army sites.

  4. What aspects of URLScan provide protection by mattsouthworth · · Score: 4, Interesting

    I've asked this everywhere, maybe someone will answer.

    The MS advisory states that a 'default' URLScan will protect against this. Well ... We don't run the default config. We've customized it, as have many shops. I can't find information on _which_ aspects of URLScan provide the protection - I'd like to know if our customizations have left us out in the breeze.

    Anyone know?

  5. Re:Ugh by Mexican · · Score: 5, Interesting

    Is it just me, or did anyone happen to download and extract the patch and notice that it does not seem to contain the webdav .dll but just ntdll.dll? So is it really a patch to WebDav or for something in ntdll.dll that webdav relies on?

  6. Doesn't help at all (example) by Wolfier · · Score: 3, Interesting

    Incompetent sysadmins still are the weakest link.

    Take a look at the World Health Organization South-East Asia web site:

    http://w3.whosea.org/index.htm

    They're running IIS 4.0. FOUR.POINT.ZERO.

    The deface has been there for almost a day with apparently no fix yet :(

  7. Slight problem with that by Groo+Wanderer · · Score: 5, Interesting

    The problem with this patch is that it wasn't found by a white hat and submitted. It was discovered by people getting hacked and calling MS asking WTF. In cases like that, 5 days isn't really that bad. In cases where an exploit, along with vulnerability code, and a description are fed to devs on a platter, open source or not, it makes the task 10x easier. When you have to figure out what is going on while under fire, and in a hurry, things get messy. That said, you can hack a lot of systems in 5 days with the right script.

    -Charlie

  8. Re:There are UNEXPLOITABLE web servers - MacOS ! by expro · · Score: 3, Interesting

    I am feeding trolls today.

    Exploits would be related to the percentage of the web actually using the platform, the number of expansive web software systems available for the platform (if you run Apache, for example, all the same exploits would apply, etc.).

    No command shell... My toaster has no command shell, either, and it has never been hacked, so it must be right. Of course, it might be a function of how many useful things you can do with it.

    No Root user... What a novel concept. I get it, just throw away all the security model, and then the problems don't qualify as security problems anyway. Pesky security machanisms were just distracting us. Real climbers never use safety ropes, because they just get in the way and cause a false sense of security!

    Pascal strings... I have certainly spent many years working with non-null-terminated strings that used a count. It is irrelevant to buffer overflows whether the size is by delimiter or by pre-count. It is a matter of whether the program (or automatic string class) checks to see if the static buffer has room for the new string based upon the sizes of the source strings. I have seen plenty of buffer overflows with counted strings for exactly the same reasons they occur in null-terminated strings.

    Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed"...Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! That explains why Macs were not vulnerable to the Word Macro exploits and a variety of other exploits -- oops, they were. Then, perhaps it is just a matter of how popular a platform it is. Let's see, no interesting modern Web Server configurations run on it, so no one uses it, and no one exploits it. A little like my daughter's TI-83, no web exploits against that, either, but it does not support the types of web aplications I want or a reasonable number of users. But no one would bother to write an exploit for it!

  9. Yes, indeed... by Tom7 · · Score: 3, Interesting

    Any safe language prevents against buffer overflow attacks, printf-style bugs, heap corruption and double-free bugs. Java or O'Caml or SML would be good choices. SML also protects against integer overflows. SML and O'Caml, for their parts, are only about 20% slower than C and a whole lot more fun to program in.

    I wrote an FTP server in SML (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/to m7misc/net/mlftpd/) so I wouldn't need to worry about buffer overflows any more. It was really easy. It blows my mind that all of the security-obsessed unix people are still manually putting in their buffer length (etc.) checks in tortured legacy C code, when they could so easily have a set of daemons that are totally immune to that sort of attack.

    Of course, any language that lets you write interesting programs (ie, "telnetd") will also let you write programs with security holes. (In a sense, telnetd is itself a security hole, provided you have the password!) But having the compiler automatically ensure that the largest class is impossible gives you a lot more time to work on other, more subtle security problems.