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.
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?
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.
So is this any kind of standard WebDAV or just a particular proprietary implementation of similar features in IIS?
I've always been curious about this technology. At one point I even heard talk of a "WebDAV filesystem", but haven't heard of it taking off in any big way yet.
"Provided by the management for your protection."
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.
I was rather hoping PHP would kill ASP off, having had the unpleasant task of maintaining a machine running Chillisoft ASP.
I remember many moons ago, there was a program that could convert ASP to PHP - I wonder if it still exists and how good it is these days if so..?
--
ALL YOUR BASE ARE BELONG TO US!
I've asked this everywhere, maybe someone will answer.
... 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.
The MS advisory states that a 'default' URLScan will protect against this. Well
Anyone know?
I think one critical issue with the timings of patch releases is stated right up there in the post: exploits are already out and about... for 3 days!
I'm not bashing either side because *nix has its security issues, too; but last time I saw an exploit with Linux, there was a patch well before any known exploits. I'm not saying the patches to Linux were made before the bug was made public, just that they were available before the bug was exploited.
If there is some cracker out there that has found this bug, then I'm sure there is a security expert that has also found and reported it. Code Red, IIRC, could've been stopped by a fix available 6 months earlier.
Of course, I'm not in any way a security expert or even amateur, and I'm not a server admin, nor did I RTFA.
IANAL, but I play one on
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?
Does this affect Windows XP Home/Pro in any way? The patch doesn't seem to apply to XP, but does the vulnerability?
At least the noticed that an exploit exists. Sure, it may take a little while to make a patch, but at least there will be a fix soon. Hopefully, this should increase the overall security of IIS, which would of course be a good thing.
Why, you may ask, would it be good for one of Apache's competitors to be less buggy (assuming you are arguing from a pro-open source standpoint)? This gives Apache competition. The more competition it has, the more incentive many of its developers will have to improve it. The quality of webservers will raise slightly.
The improvement of IIS is also a good thing for buisnesses that rely on it because of ASP. Perhaps they wish to move to Apache, but cannot because of their language of choice for development on their webserver. Should they be more vulnerable to hacker attacks, just because of their choice of language? No.
The conflict between Apache and IIS is generally a good thing.
"Eventually MSFT will have to deliver your "mission critical" ASP runtime for Apache, and the world will be a better place because of it."
Why wait for Microsoft when ASP.Net is already being ported?
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
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
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!
Not to mention that the first two are for Apache running under Windows. *cough*
Why would you run a IIS server without using the lockdown utility??
Good point. However, my company advises our clients against running it, mainly because their sysadmins are...not well versed in the arts of running a windows web server. The default configuration for the lockdown tool shuts down everything except for HTML. That includes the ASP engine, which our product requires. If the sysadmin spends a few minutes to go through the list of what to disable and what not to, they're fine.
Sadly, our clients just blindly run it and then panic when the whole site ceases functioning. Usually they delete the lockdown tool (instead of reversing the changes, which you would know you could do if you read the documentation-they don't), and then call us and claim "It just stopped working! We didn't change anything!". A little later, we find out what they really did and fix things. In the end, we've found its better to just tell them to disable what they don't need by hand based upon documentation we provide, and avoid the whole problem with the lockdown tool.
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.
o 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.
I wrote an FTP server in SML (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/t
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.
I love that list of vulns for apache!
Not only are they older, they almost all have one thing in common: they are for apache on Win32.
Only one or two of the seven affected a UNIX platformed apache.
It seems that the vulns for Win32 revolve around getting the '/' vs '\' right and how they do their path checking.
Neither have you.
I have. It's a fucking long and headache-inducing read, so I'm quite certain I'm one of very, very few people to do so.
The short of it? Yes, people have every right to despise Microsoft; they are absolute scum. Their behaviour during the trial was nothing less than disgusting. Somebody pulled a lot of strings to get them off the hook, rather than being flat-out dissolved and having their assets siezed.
Case in point: When's the last time you saw someone not get the judicial version of a savage beating after submitting false evidence, even in a civil suit? Aside from Microsoft.
You may be correct in your position regarding this software firm, but it's only because you made a good guess.
In your enthusiasm to slam Microsoft, I get a Really Good Feel for when a patch is critical or not. It lets me ignore the servers until a front page Slashdot article shows up.
So, Danke!
"Draco dormiens nunquam titillandus."
Agreed, yada yada yada.
Granted, I've more experience with Apache than IIS, so if my post was in error its certainly understandable. That was my understanding from previous IIS vs. Apache tests, was that part of IIS ran in kernel mode to serve pages faster, and that was one reason many remote exploits were so serious.
Regardless, we have 2 IIS servers here at work, that are accessible to the Internet, and that has never been a problem. We keep them up to date, run the lockdown tool, so on. It really isn't too difficult to keep secure. Same goes for Apache.
Sitting on security vulnerabilities until several fixes are available and releasing them as one advisory is a good trick to try to reduce the overal number of advisories, without actually having to improve the quality or security of the product.
For a while patches were announced on Thursdays and for a while before that it was Fridays. Fridays must have run too much overtime and shown up on the boardroom radar. Thursday in Seattle is already Friday in Europe so maybe this is a play to get MSTD-induced overtime back off the radar of European managers. With a legal cap of around 37.5 hours per week per tech, business can't afford too many IIS servers.
It is strange that any would try to. Microsoft-IIS is not a viable alternative to Zeus or Apache.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.