Slashdot Mirror
Major Security Flaw in IIS4.0
Mintslice was one of the first to write in with the latest major major hole that's been found in Microsoft's IIS4.0. The hole, a nice little number, called remote users can gain root access, using buffer overflow is "being treated" seriously by the corporation. Mmm...Apache.
1. Remove the extension .HTR from the ISAPI DLL list. Microsoft has just
updated their checklist to include this interim fix.
Here's where the 90% of public ISS servers figure probably is not true. A standard security recommendation for IIS is to disable ISAPI extensions that are not in use. As for how many people use HTR, I don't know, but I'd guess it's not 90%. If your local IIS admin hasn't done the basics such as this, this is a gentle reminder.
And as for the folks crowing about Unix versus NT security, you know there's lots of stuff you can run on a Unix box that will create security holes. Certain Linux installers will automagically activate some of this stuff. The fault with Microsoft here is shipping a product with pre-activated 'features' that you many not want to use. (Third party ISAPI extensions require manual registration - a 30 second process). Obviously the more untested, unused features you might have running, the more security holes you are exposed to.
Of course with Unix and open source products, you can be somewhat sure that someone is trying to find the holes for you. But, IIS is a pretty immature product, despite it's version number, so I don't know if you can say the same for Unix software that hasn't been in the field for many years.
--
Business. Numbers. Money. People. Computer World.
I really like the apparent strategy of these security companies, who, when they become the first to find a hole, get a whole lot of good PR and advertising.
I think this is a classic case of the vapor/pre-marketing/beta-release methodology Microsoft has used to claw back turf it lost when they discovered maybe CERN and NCSA were on to something with HTTPD.
First off, Windows has always been behind on web servers. Remember EMWAC? The Win32 platform suffered by being so different from Unix that any port of new Unix-based packages requires Herculean effort to bring to Windows.
Apache has time in service, legacy, and flexibility on its side. What Microsoft has that Apache is missing is 9 figures worth of PR.
Microsoft rolled their own, with a view to pitching it as a central part of the OS. I mean, I don't think I've ever seen a Solaris slick with a "now featuring APACHE!" starburst across the top. It's just always been there, or at least readily available. Microsoft has had the luxury of selling the most rudimentary services and tools (HTTP, NNTP, mailer, even scripting) as quantum leaps in OS evolution.
Unix types know three things when it comes to software:
1) It's probably in there;
2) If it's not there, I can probably find and install it; and
3) If it breaks, I can probably fix it.
Windows folks, by contrast, have been trained to follow the path of least resistance by being spoon-fed these black boxes that inevitably blow up in their faces. An exploit like this shows up on CERT or Rootshell, and everybody.asp is a sitting duck. Sooner or later, CIOs are going to catch on here.
They sure can sell the stuff, though. So well that the marketing folks can compromise the reputations of otherwise superlative programmers.
Let me get this straight. Your idea for fixing the scalability problems of Sendmail is to create a config file format that takes MORE horsepower to parse (regular expressions)?
I'll agree Sendmail needs a major overhaul and that the config file format is a disaster, but let's face it, anything as flexible as sendmail will have the same scalability problems as sendmail. The only solution to those scalability problems is to go with a less flexible MTA. Sort of like in web server, where if you want flexibility you go with Apache, but if you want speed, you go with thttpd or Zeus.
-E
Send mail here if you want to reach me.
Think about it. These systems are *web servers*. They are Internet connected and already configured to deliver files to remote systems. The worm need only deliver a small piece of seed code that uses an HTTP request to pull the entire package down from the attacking system. The cracked system then sets up its own downloadable worm package and then starts probing for other IIS servers to deliver it to. This could sweep through the Internet like wildfire.
Scary. I am VERY glad my business is running on Apache.
Thad
The Bolachek Journals
This might look like flamebait, but this is exactly the reason that people should be weary of Microsoft products.
In Unix's long history, there have been many vulnerabilities and problems that have popped up. We've had problems with sendmail, ssh, etc., and all of these utilities went through a lot of modifications and change, but they're becoming quite secure. I see less and less security problems with these utilities.
There was a saying that said that if you don't learn unix, you're are bound to reimplement it.. badly.
Microsoft's tools are not proven. They do not have the years of maturation that proven UNIX servers and utilities do. Sure, Unix is 30 years old, but that makes for a far mature and proven operating system.
Microsoft's servers are closed source, so we cannot verify the quality of the security of the code, and we cannot fix them quickly if there are problems.
Is it any wonder that Apache has such a huge marketshare? What is there to give us confidence in the code in IIS? Marketing and Public Relations? Isn't technical merit far more important?
It seems to me that if we went back to a sane system in which DATA and STACK pages were never executable -- just readable and writable -- and TEXT pages were never writable -- just readable and executable -- that a lot of these problems would mysteriously evaporate. Oh, I can see how you could write incorrect data on the stack in a frame you shouldn't be doing that to (a caller's frame data), but at least you could never write code that would actually be executed. This would to my eye seem to raise the bar at the security gate to a non-trivially higher notch.
Retina vs. IIS4, Round 2
.ASP, .IDC, .HTR). The way we think the exploit will take
/[overflow].htr HTTP/1.0" it had crashed the server.
:)
.HTR extensions. IIS includes the /iisadmpwd/. This feature is implemented as a set of .HTR files .HTR/ISM.DLL ISAPI filter is installed by default
.HTR from the ISAPI DLL list. Microsoft has just i st.asp
9 99/ad06081999.html
9 99/ad06081999-brain.html
Systems Affected:
Internet Information Server 4.0 (IIS4)
Microsoft Windows NT 4.0 SP3 Option Pack 4
Microsoft Windows NT 4.0 SP4 Option Pack 4
Microsoft Windows NT 4.0 SP5 Option Pack 4
Release Date:
June 8, 1999
Advisory Code:
AD06081999
Description:
We have been debating how to start out this advisory. How do you explain
that 90% or so of the Windows NT web servers on the Internet are open to a
hole that lets an attacker execute arbitrary code on the remote web server?
So the story starts...
The Goal:
Find a buffer overflow that will affect 90% of the Windows NT web servers on
the Internet. Exploit this buffer overflow.
The Theory:
There will be overflows in at least one of the default IIS filtered
extensions (i.e.
place is that IIS will pass the full URL to the DLL that handles the
extension. Therefore if the ISAPI DLL does not do proper bounds checking it
will overflow a buffer taking IIS (inetinfo.exe) with it and allow us to
execute arbitrary code on the remote server.
Entrance Retina:
At the same time of working on this advisory we have been working on the AI
mining logic for Retina's HTTP module. What better test scenario than this?
We gave Retina a list of 10 or so extensions common to IIS and instructed it
to find any possible holes relating to these extensions.
The Grind:
After about an hour Retina found what appeared to be a hole. It displayed
that after sending "GET
We all crossed our fingers, started up the good ol' debugger and had Retina
hit the server again.
Note: [overflow] is 3k or so characters... but we will not get into the
string lengths and such here. View the debug info and have a look for
yourself.
The Registers:
EAX = 00F7FCC8 EBX = 00F41130
ECX = 41414141 EDX = 77F9485A
ESI = 00F7FCC0 EDI = 00F7FCC0
EIP = 41414141 ESP = 00F4106C
EBP = 00F4108C EFL = 00000246
Note: Retina was using "A" (0x41 in hex) for the character to overflow with.
If you're not familiar with buffer overflows a quick note would be that
getting our bytes into any of the registers is a good sign, and directly
into EIP makes it even easier
Explain This:
The overflow is in relation to the
capability to allow Windows NT users to change their password via the web
directory
and the ISAPI extension file ISM.DLL. So somewhere along the line when the
URL is passed through to ISM.DLL, proper bounds checking is not done and our
overflow takes place. The
on IIS4 servers. Looks like we got our 90% of the Windows NT web servers
part down. However, can we exploit this?
The Exploit:
Yes. We can definitely exploit this and we have. We will not go into much
detail here about how the buffer is exploited and such. Read the comments in
the asm file for more information. However, one nice thing to note is that
the exploit has been crafted in such a way to work on SP4 and SP5 machines,
therefore there is no guessing of offsets and possible accidental crashing
of the remote server. We have not tested the exploit on SP3 and would love
to know if it works or not. eMail alert@eEye.com if you've successfully
exploited this hole on SP3.
For more details about the exploit visit the eEye web site at www.eEye.com
The Fallout:
Almost 90% of the Windows NT web servers on the Internet are affected by
this hole. Everyone from NASDAQ to the U.S. Army to Microsoft themselves.
No, we did not try it on the above mentioned. But it is easy to verify if a
web server is exploitable without using the exploit. Even a server that's
locked in a guarded room behind a Cisco Pix can be broken into with this
hole. This is a reminder to all software vendors that testing for common
security holes in your software is a must. Demand more from your software
vendors.
The Request. (Well one anyway.)
Dear Microsoft,
One of the things that we found out is that IIS did not log any trace of our
attempted hack. We recommend that you pass all server requests to the
logging service before passing it to any ISAPI filters etc...The logging
service should be, as named, an actual service running in a separate memory
space so that when inetinfo goes down intrusion signatures are still logged.
Retina vs. IIS4, Round 2. KO.
Fixes:
1. Remove the extension
updated their checklist to include this interim fix.
http://microsoft.com/security/products/iis/CheckL
2. Apply the patch supplied by Microsoft when available.
http://microsoft.com/security
Vendor Status:
We contacted Microsoft on June 8th 1999, eEye Digital Security Team provided
all information needed to reproduce the exploit. and how to fix it.
Microsoft security team did confirm the exploit and are releasing a patch
for IIS.
Related Links
Advisory - On our web site
http://www.eEye.com/database/advisories/ad06081
Advisory - Retina Brain File used to uncover the hole
http://www.eEye.com/database/advisories/ad06081
Retina - The Network Security Scanner
http://www.eEye.com/retina/
Greetings go out to:
The former Secure Networks Inc., L0pht, Phrack, ADM, Rhino9, Attrition, HNN
and any other security company or organization that believes in full
disclosure.
Copyright (c) 1999 eEye Digital Security Team
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail alert@eEye.com for
permission.
Disclaimer:
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.
Please send suggestions, updates, and comments to:
eEye Digital Security Team
info@eEye.com
www.eEye.com
With a properly configured sendmail-8.8.5 distribution, or above, I'd like to see you back this assertion up with some facts. Go ahead and show me how you'll crack a box with sendmail using a buffer overflow or other similar trick... you're not leaving sendmail in debug mode are you?
.cf, smrsh configured, and no DON'T_BLAME_SENDMAIL options blatently leaving your machine open to the world. The current release of Sendmail is 8.9.3, I haven't seen a CERT advisory on sendmail for some time, and Eric Allman keeps pumping out new bugfixes.
Now by properly configured, I mean no configuration files down a path with group writable directories, no stupid scripts run out of the
This doesn't diminish the good work done by the qmail folks. However, if you want UUCP, BITNET relaying, or FIDO-NET support (which is CRITICAL in many third world countries) sendmail is your only option.
Finally, your post is flame bait devoid of relevant information to the IIS security hole. Of course, this reply is also devoid of anything relevant to the IIS security hole found, but I thought it incumbant to reply to your misinformed banter.