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.
Why is it that so many programmers think that the world would be a better place if everyone would just use their favorite language?
Save the whales. Feed the hungry. Free the mallocs.
I once got the crap flamed out of me for saying the exact same thing as the original AC, years ago on BUGTRAQ. Ghod forbid anyone should question the Language of Choice... if you can't drive a car with square wheels, you just aren't a good enough driver. If you aren't willing to ditch the C stdlibs and start over from scratch, you're just not a serious programmer.
What a load of crap!!! It's the sort of snotty elitism that compares well to, say, Custer's Last Stand.
How about if your NT box isn't secure, you're just not a good enough administrator? No suggestion that if you used Unix, you might not have to DEAL with some of these problems?
C is a beautiful, wonderful language for writing operating system kernels and low-level utilities. But it's a lousy language for writing security-sensitive code... it's nearly impossible to prevent buffer overflows without years of experience and studious avoidance of what are and should well be standard coding practices (sprintf(), for example).
C++ not only saddles you with the same buffer overflows, but often buries them deep inside classes, behind badly mangled names, hidden from the probing of debuggers. Of course, if you don't throw out all standard libraries and start from scratch, you're not a good C++ programmer either, right?
Dylan is a solution, but not the only solution. Even Perl is basically immune to buffer overflows, at some performance penalty. Most languages designed for use other than writing OS kernels do automatic bounds checking, and even garbage collection (getting rid of all those pesky memory leaks you admit to in the process).
Don't turn your nose up at using the right tools.
Hand me that airplane glue and I'll tell you another story.
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.
This should be a good test of commercial software versus free. The Linux DoS bug was patched within hours - lets see how long MS takes to :
a) admit the problem (if ever)
b) fix it
Chris Wareham
Anybody remember this article
http://www.microsoft.com/technet/av ail/ebay.htm
regarding The Importance of Reliability in an e-Commerce World....
I just sent this article in responce to it (technet@microsoft.com) God, I amuse myself...
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.
of course, they didn't break anything else either. that's why i run linux.
so quit sniping at a decent MTA that runs circles around most others as a turnkey messaging system.
Its pretty obvious from the data in the registers after the crash that it works. Just in case you know nothing about the x86 line, I'll enlighten you. the fact that ECX and EIP (EIP is the instruction pointer, use your imagination) are filled with 0x41414141 (0x41 is the letter 'A', which is what their overflowing buffer was filled with). So obviously, the instruction pointer is overwritten, allowing the attacker to point EIP back into the buffer, executing their code. Not theoretical at all. The reason sites aren't going down left and right is that the security outfit that found this didn't give out their own test exploit, and people who know how to write one don't give them to script kiddies. An exploit has usually been known about by professionals for a while before it shows up on rootshell.com. The only reason script-kiddie attacks are so sucessful is that admins don't patch to fix holes that have been known about for years.
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
Your comment doesn't completely address his concerns. Being able to sneak an arbitray return address allows you to execute almost arbritrary code whether the stack is considered executable or not.
With a commerical product like IE, the attacker will have complete knowledge of all the code loaded into memory. Just jump to some bit of normally executable code in memory that does what you want. On an Intel chip, you don't even have to jump to an instruction that originally existed. Jump into the middle of an instruction and you get code that the designers never intended to be put there.
I fervently hope that this bug is used to repeatedly down the stock market and a few military computers. That would put the spotlight like nothing else on Microsoft's failings.
Need a Python, C++, Unix, Linux develop
Stone age programming technology? C++ is certainly not that. Strings can be handled with class to do all neccessary bounds checking..Thaer, it's programmmers deciding to use a char[] in an improper place.
Perl and Java can both be compiled to (real) machine code; their speed in these situations is close to C++ -- at least, close enough to justify coding in them. (Although I agree that coding real applications in interpreted Java is total folly, at least on today's machines.)
"Whatever happened to fair use?"
-- Duff-Man
Microsoft Security Bulletin (MS99-019)
.HTR files. HTR files enable remote administration of user passwords.
.HTR file could overflow the buffer, causing IIS to crash. The server would not need to be rebooted, but IIS would need to be restarted. The second threat would be more difficult to exploit. A .HTR files.
i n.asp for more information about this free customer service.
.HTR files as follows:
C heckList.asp
9 -019.asp.
C heckList.asp
f ault.asp.
- ------------------
--------------------------------------
Workaround Available for "Malformed HTR Request" Vulnerability
Originally Posted: June 15, 1999
Summary
=======
Microsoft has released a patch that eliminates a vulnerability in Microsoft (r) Internet Information Server 4.0. The vulnerability could allow denial of service attacks against an IIS server or, under certain conditions, could allow arbitrary code to be run on the server.
Microsoft has issued this bulletin to advise customers of steps they can take to protect themselves against this vulnerability. A patch to eliminate this vulnerability is being developed, and an update to this bulletin will be released to advise customers when it is available.
Issue
=====
IIS supports several file types that require server-side processing. When a web site visitor requests a file of one of these types, an appropriate filter DLL processes it. A vulnerability exists in ISM.DLL, the filter DLL
that processes
The vulnerability involves an unchecked buffer in ISM.DLL. This poses two threats to safe operation. The first is a denial of service threat. A malformed request for an
carefully-constructed file request could cause arbitrary code to execute on the server via a classic buffer overrun technique. Neither scenario could occur accidentally. This vulnerability does not involve the functionality of the password administration features of
While there are no reports of customers being adversely affected by this vulnerability, Microsoft is proactively releasing this bulletin to allow customers to take appropriate action to protect themselves against it.
Affected Software Versions
==========================
- Microsoft Internet Information Server 4.0
What Microsoft is Doing
=======================
Microsoft has provided a workaround that fixes the problem identified. The workaround is discussed below in What Customers Should Do.
Microsoft also has sent this security bulletin to customers subscribing to the Microsoft Product Security Notification Service.
See http://www.microsoft.com/security/services/bullet
What Customers Should Do
========================
Microsoft highly recommends that customers disable the script mapping for
- From the desktop, start the Internet Service Manager by clicking Start | Programs | Windows NT 4.0 Option Pack | Microsoft Internet Information Server | Internet Service Manager
- Double-click "Internet Information Server"
- Right-click on the computer name and select Properties
- In the Master Properties drop-down box, select "WWW Service", then click the "Edit" button .
- Click the "Home Directory" tab, then click the "Configuration" button .
- Highlight the line in the extension mappings that contains ".HTR", then click the "Remove" button.
- Respond "yes" to "Remove selected script mapping?" say yes, click OK 3 times, close ISM
A patch will be available shortly to eliminate the vulnerability altogether.
Customers should monitor http://www.microsoft.com/security for an announcement when the patches are available.
Microsoft recommends that customers review the IIS Security Checklist at
http://www.microsoft.com/security/products/iis/
More Information
================
Please see the following references for more information related to this issue.
- Microsoft Security Bulletin MS99-019,
Workaround Available for "Malformed HTR Request" Vulnerability (The Web-posted version of this bulletin),
http://www.microsoft.com/security/bulletins/ms9
- IIS Security Checklist,
http://www.microsoft.com/security/products/iis/
Obtaining Support on this Issue
===============================
If you require technical assistance with this issue, please contact Microsoft Technical Support. For information on contacting Microsoft
Technical Support, please see
http://support.microsoft.com/support/contact/de
Revisions
=========
- June 15, 1999: Bulletin Created.
For additional security-related information about Microsoft products, please visit http://www.microsoft.com/security
-----------------------------------------------
Oh, this is fully exploitable.
Perhaps the people who released the advisory wanted to wait for a patch from MS before releasing their exploit...
It's going to be a very scary couple of days. I would suggest that any IIS admins fix things right away...
This kind of hole could be used very easily to run an "egg" that would open a remote command shell, or install NetBus or Back Orifice 2000
http://www.bo2k.com
Watch that space, and remember DefCon is July 9-11 in Las Vegas.
I cannot believe that the disadvantages of selecting an alternate implementation would be greater than the advantages of not letting anybody splat their own code in a perfectly running program and have it execute that user code.
Self-modifying code may be nice for Core Wars, but it sucks for security verification.
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?
I think, IMHO, that the Un*x community should stop helping M$ by divulgating security holes in their products. Let's keep everything for ourselves and then crash every single M$ server so that they'll be too down to spit on the open community ever again.
I believe M$ is able to organize some bugs "discoveries" in a well organized way so they already have a miraculous patch ready for it. I'm maybe paranoid, but knowing M$ it wouldn't surprise me.
No pity!
Reporter: "What do you think of Western Civilisation?"
M.K. Gandhi: "I think it would be a good idea."
-- It's always darker before it goes pitch black.
For what it's worth; I've been using Exim now for quite a few months and has found it very capable of doing everything that sendmail once did for me. In fact; Exim provides quite a few methods that gives functionality which I would only have dreamed of in Sendmail. Exim is also released mostly under the GPL (three pieces of code exists which is not GPLed, but I think it would be possible to leave them out if one is a purist).
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.
(Microsoft has acknowledged the bug, so the first half of your question is complete.)
.HTR extension from IIS (the post on Bugtraq lists .ASP and .IDC as being affected as well). The funny thing is their terminology and timeline. At the top it says, "Originally Posted: May 27, 1999." So they knew about it a whole 11 days before eEye told them about it. Posted where, you might ask? Who knows. But at the bottom of the page it says, "June 15, 1999: Bulletin Created." I presume that "bulletin created" means they put it on their web site. Even still, not only with a week's notice, but 18 days notice the bug is not fixed.
I was curious just how quickly the ICMP attack took to fix, so here is my 5 minute investigation, it's taken longer to write this than research it. Kudos to the folks at Progressive Computer Concepts for their excellent mail list archives ( www.progressive-comp.com). I assume the date/times listed are in their local time.
Bug Notice: Posted to Bugtraq by Piotr Wilkin 1 June 1999 15:43:17.
Solution: Posted to Linux Kernel by Alan Cox, 1 June 1999 22:23:04. Also Posted to Bugtraq by Alan Cox, 1 June 1999 22:30:33.
So, 6 hours, 39 minutes, 47 seconds from the time it was made public to solution (7.5 minutes more if you only monitored Bugtraq).
And then this IIS bug, reported to Microsoft 8 June 1999, made public on Bugtraq at 12:18:16 today (15 June 1999). A week lead time, and no fix in sight.
Security is the heart of any business that relies on its web page for income (order taking, etc). Now that it's been made public, I'm sure all the skript kiddies will be wreaking havoc this evening on as many servers as they can hit. Although, for completeness, I'd be interested in noting any servers that do get hit. The Wired article specifically mentions Nasdaq, Disney, and Compaq as running "large ecommerce operations" on IIS. I can't imagine how a large company could stick with it with such pathetic service from MS.
Oh wait. I went to the security web site listed in the article, and MS has posted a workaround, basically remove the
Other inconsistencies in the notice, in the "What Microsoft is Doing" section, "Microsoft has released patches that fix the problem identified" (my bold). Oh, it's been fixed by golly. Then you go down to the "What Customers Should Do" section (be it 4 lines down, web design cracks aside) like they say next, what does it say? "A patch will be available shortly..." So it's fixed, but you cannot have it. This just makes my point even better. Why rely your business on them with this double-talk and no real solutions??