Slashdot Mirror
Remote 'Root' Exploit in IIS 5.0
eEye Digital Security
was doing some testing that apparently Microsoft hadn't done on its own webserver (IIS 5.0) running on its latest OS (Windows 2000, all versions). "Within a matter of minutes," they say, "a debugger kicked in on inetinfo.exe because of a 'buffer overflow error'" -- and two weeks later, we got simultaneous announcements from Microsoft and eEye. This is a remote SYSTEM-level exploit in a popular webserver, in the wild, i.e., Danger Will Robinson. eEye says about a million servers will need to be patched;
it may be more.
Go see
Microsoft's writeup and patch.
See also
eEye's droll and informative writeup,
which, now that an exploit is confirmed to be in the wild today, has added some source code.
Will the 'fix' from Microsoft involve IIS running with user level privs? I betcha it won't.
Actually the restart feature applies to all W2K services. You specify what to do on the first and second explicitly, and then on subsequent. The options are to restart service, reboot computer, take no action, or run an external program (such as a pager alert program). By default it is set at take no action, meaning the service dies and stays dead until manually restarted.
CmdrSprk writes: Another MS Bug FA-MSP Editor Biachezzzz!!!!! I 0wn3z j00! Sporks rule!
This could enable a remote attacker to conduct a buffer overrun attack and cause code of her choice to run on the server. Such code would run in the Local System security context. This would give the attacker complete control of the server, and would enable her to take virtually any action she chose.
Only females can exploit this hole!*
*Not to be taken out of context
actually, it's not quite so easy. i wrote the exploit, and inititally looked at creating a fix as the initial exploit and ran into the following problems: 1. deleting the file: if you delete the printer dll, it is replaced by the copy in dllcache. if you delete the one in dllcace, it gets replaced by the original. if you delete both at the same time, it then asks for the original install media. self healing files are cool until they reintroduce the problems. 2. removing the extension: there isn't a really easy way to deal with the metabase(the registry like structure used in dealing with iis) using asm 3. size: writing an exploit with around 400 bytes, taking into effect that you have to load addresses and data and have some boot strap code, not to mention that you have to split your code into 2 segments because the buffer overflows right in the middle. if anyone has questions as to why, or how, let me know. i'd be more than happy to explain both to serious inquiries. ryan permeh, ryan@eeye.com
- A.P.
--
Forget Napster. Why not really break the law?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
No, the install should simply be secure by default. I would apply the same standard to Linux distributions, and they often fail the test. Microsoft isn't alone here but I don't think this makes it "right". It just makes it common.
That's a local (not remote) root exploit in a not-commonly-installed tool.
That's a remote unprivileged-user (not root) exploit in a not-commonly-installed application.
That's a local (not remote) non-root exploit in a not-commonly-installed application.
That's, um, a DoS against Novell Border Manager.
I know it's fun and easy to bash Slashdot for being anti-Microsoft, especially when we report security news, but we don't ignore open-source problems and we only report vulnerabilities which are of pressing and widespread concern.
Jamie McCarthy
Jamie McCarthy
jamie.mccarthy.vg
This exploit is more serious than the others you've listed. It's a remote root exploit, and it affects people who take the out of the box installation.
/.
A comparable Unix exploit would have been the recent BIND fiasco. And that got good coverage on
I get tired of MS bashing too. But I think there's a lot less of it here than there used to be. The article about Easel and Ximian took a lot of heat, but I think it was a healthy thing to post. We're still a long way away from looking at the ethics of some of the Linux IPOs, but it's a start.
This is a big security problem, and it was made worse by some questionable design decisions (automatic restarts, etc.). But the effect isn't really any worse than the recent BIND exploits.
And you could argue, as perhaps the OpenBSD guys might, that by not advising people to run BIND in a chroot jail, the ISC guys are being less responsible than MS, which has published security guidelines that protected the users who followed them from this particular exploit.
But what good does that do? The reality is that both Linux and Windows have their share of security problems. MS has a long list of bad decisions from a security point of view, but we have things like linuxconf. Sacrificing security for convenience isn't just a MS thing. And there are plenty of buffer overflows to go around.
We need to encourage everyone to think about security more seriously. We need to get companies to think about security from the beginning, instead of trying to bolt it on in the end. And we need to make sure that they respond quickly when problems do arise.
This just isn't a Linux vs. MS situation.
Quite so. The weary WebAdmin, as well as the SysAdmin and Network Operator can all sleep easy knowing that Joe RandomScriptKiddie is remotely administering the latest updates to their Win2000 servers for them.
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
What if it's crawling or limping, as would be more likely than "running?"
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Yawn, I'm not going to go over this argument yet again. The bug is essentially this one instruction:
mov [ebp+var_4], 202h
when the buffer is actually only 101h bytes long. So eEye could of made a one byte patch and released this, fixed the problem and then gone to Microsoft to get them to fix it in the source. But that's not the way it goes down. Microsoft has to be the one that makes the patch and although they beat the 30 day average I think 11 days to release a patch is pretty shameful (openbsd would patch this in under 6 hours, 24 hours being the maximum). Especially considering that mumblings of this bug were on bugtraq before April 19.
How we know is more important than what we know.
The vast majority of security vulnerabilities are buffer overflows. This latest vulnerability extends this status quo. There are technologies out there that prevent this, however, almost all of these technologies slow down the system in some way or another. Examples include languages that allow dynamically sized arrays and other preventative measures.
CPU speed is growing such that it would appear that we could take a speed hit for increased security. Is it coming down to the fact that various organizations would rather market a fast webserver at the expense of a secure one? The $64,000 question is why the industry has not moved towards safer technologies that prevent these security holes.
Not that Microsoft is incredibly innovative on the security front, but they're hardly the only culprit. Many others rely on unsafe languages and techniques that allow these vulnerabilities to leak through.
When will it end? Is there any incentive to end?
Of course, I'd be pretty upset too if a bunch of upstarts were singlehandedly obsoleting my practices and methodologies, like eEye (and groups like them) has done with "traditional" security consulting and management. I just hope all you people are watching now and paying attention to the contributions the security community gets from eEye's critics.
A published root hole in IIS is a coup for open source (when was the last "Administrator" break from Apache?). The disseminated fix will be a coup for full disclosure. Everybody wins. Except the dinosaurs.
Thats the most common problem with server security, is the lack of knowledge of some of the administrators setting them up. They don't truly know what is running either via way of moronically not being intuitive enough to know what ports are open for what services and why, or just not having a clue altogether.
Funny how many would whore out including the staff of eEye. Instead or placing a nicely written morally sound write up, they overhype the issue to promote their product.
Lets not forget, what goes around comes around as eEye has seen in the past. I've purchased programs via my company from eEye, and they're not all that, nor are their advisories. Someone should teach those guys humility.
As for Microsoft, its just another one of their flaws, so I don't see what the big deal is.
removing the dot in dot com
Want Root?
Since MSs products do this that the other thing and the last thing you ever want to do but not the thing you need to buy the 3rd party software for, is it really any surprise MS always suffers from escaped code review buffers? When you bite off more than you SHOULD chew, this 'll always happen. =)
.. more granular projects lead to better security ...
Its a good thing for the OS community
Garret
"Old man yells at systemd"
Apache can run VB based ASP via closed addons from Chillisoft and Halycon software and Perl based ASP using Apache::ASP (I think that's what its called), an open source app.
Apache can also authenticate against NT domain security using the SMB PAM module.
IIS is administered through a standard interface which is very friendly. There are a few of these available for Apache, most notably a great Webmin module.
Many old versions of Apache modules were a bitch to package (ie. PHP3). Newer ones (ie. PHP 4) package great, but compile-heads who prefer using non known-good software that isn't supported by their distro because it satisfies their pathetic egos still like compiing, and less epxerienced admins think that's the standard way to do it.
And its SYSTEM, not 'root', on an NT box.
As many people have pointed out, anyone reasonably experienced, and any "real" website, isn't vulnerable to this if they followed the best practice of deleting all app mappings that aren't in use. It's like the blank SQL sa password all over again. Easy to get worked up about, pretty much a nonissue for anyone who even halfway knows what they're doing.
Right. And millions of stolen credit card numbers as a result is only proof of stupid admins, not stupid software.
Software has an obligation to setup secure by default, and insecure by the expressed will of the admin. Apparently with IIS and/or MSSQL this little bit of advice is forgotten.
You can go on and on about how anyone who bothered to read the docs would not setup the server in a vulnerable way, but this ignores an INCREDIBLY important aspect of human nature. That default computer usage should be reasonable is assumed by default. 80+% of all web users NEVER change their home page. In a simliar vein, most web admins simply use the default install, irrespective of the potential holes pr default passwords.
The default install has to work securely, plain and simple. For IIS or MSSQL, there are obvious reasons that your customers' business is not safe if you used the default install.
Because unlike apache on unix, IIS has a built-in facility to let "webs" and "subwebs" take on different user priviledges.. giving not only a sort of "run-as" functionality to web apps easily, but also leveraging the NT security model for isolation between separate websites and apps on the same webserver.
To do this with apache, well, you're talking about extensions and helpers that break parts of apache and are security risks in their own right... "suexec" comes to mind... and apache still needs to run as root to let any of these work. Furthermore, does suexec work with php ? mod_perl ?.. or is it only a cgi-bin wrapper (i.e. killing apaches performance as a dynamic content server)
Fwiw, there may be better solutions than the old suexec on apache by now...
it is possible that via perhaps Impersonation, IIS could run as non-system and still have separate users and app protection etc, but thats tricky to program. There may be other reasons for IIS to run as system; what i've written is just a possibility.
My opinions are my own, and do not necessarily represent those of my employer.
"However, this couldn't be used to conduct an effective denial of service attack, as the IIS 5.0 service automatically restarts itself after a failure. " If it takes me like one packet to shutdown the service(Hence the restart). I can generate lets say 4 packets per minute? (I really do have a better connection but) If I can not keep an IIS server thoroughly enough pissed with a small attack to prevent users Im confused. Not that I would but I just refuse to believe that while IIS is automatically restarting itself users would not be denied service. Oh well two cents. minus a dollar.
I am 31337 or something.
I don't have numbers (probably only large espionage organizations do), but I'm willing to bet that's not true.
Buffer overruns undeniably get a lot of coverage on bugtraq--if you casually read the list, you'll be forgiven for thinking that buffer overruns are the overwhelming bane of computer security. But there are two biases to this observation:
-
Buffer overruns get more talk than vulnerability reports. Go to the vulnerability database at SecurityFocus and browse the recent
reports. On the first
page, there are 28 vulnerabilities, of which only three explicitly
mention buffer overruns. Even assuming that this is an unusually low
number, and that a few buffer overruns aren't labeled as overruns, and allowing that buffer overruns tend to be more serious than the
average vulnerability, this is hardly a preponderance.
-
bugtraq report statistics probably over-represent
buffer overruns. This is related to the above discussion--buffer overruns
are popular and well-worn ground. If you report one, everyone will
understand it and you'll win sure ego points. So if you're going to search
for vulnerabilities, you'll probably search for buffer overruns.
In short, even if we stop using languages with unsafe pointers tomorrow, our security woes will continue in full force.I frankly think the reason the discussion on bugtraq seems dominated by buffer overruns is that the community enjoys, and is comfortable, discussing buffer overruns. Even though the same religious issues (bounded arrays, language choice, non-executable stack, stack-guarding libraries) are rehashed over and over, people never get tired of them. Buffer overruns have a cherished place in security folklore. This is kinda nice in that it gives the community a common ground, but dangerous because it leads people to overlook the importance of other program flaws that can result vulnerabilities.
Further, buffer overruns are plain easy to find. If you have source code, a few greps often take you right to the hole. Even if you don't, tools like fuzz do pretty well (many bugtraq reports indicate that tools like this were used to find the overrun). Plus, contrary to what you might think, buffer overrun exploits are ususally easy to write, so don't think that turns of any would-be security gurus. Other classes of vulnerability usually require more analysis of program logic to find.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Does anyone have a program that will exploit the hole and run code to automatically remove the .printer ISAPI mapping, then crash IIS so it will automatically restart with the new, safer configuration?
That would be a White Hat job.
NO CARRIER
Ok, so there's a major security flaw with Windows 2000 server computers running IIS 5.0 because this ISAPI extension is installed by default. A patch is already available, and for those who don't want to patch (why the hell not?), they can simply remove the extension.
Yes, this seems to be a really nasty hole, but it doesn't appear as if it's been exploited (yet, of course). Microsoft did release a patch and didn't try to play down its importance (so it seems to me). Those of us in the *nix community have had our share of root exploits in various daemons, so they crop up in even our most favorite software.
There is no reason to be blindly insulting MS or promoting the secureness of Open Source programs. Large, complex programs are subject to buffer overruns.
If you have a Win 2000 server or know someone that does, just get the patch. Simple as that.
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
You only come down really hard on the kid that is always in trouble...
/.ers only have a karma of 49...
REAL
SIG: HUP
Let Microsoft take you away from all that. With our new RemoteRoot feature for IIS on Windows2000, users can log in as root from remote sites without all the muckety muck.
Forgot your password? No problem. RemoteRoot makes getting in easy.
Microsoft has partnered with the company responsible for Zero Click technology to bring you this wonderful new feature. You can read more about it on their web site.
The MS writeup clearly states "Note: The vulnerability is only exposed if IIS 5.0 is running."
So in effect, if the admin who setup the webserver is in ANY way competent, he should have already been over the checklist and applied the template, both of which discuss removing this extension. If he's lazy and only used the SecTool, that would still do the job.
-------
-- russ
"You want people to think logically? ACK! Turn in your UID, you traitor!"
Natural != (nontoxic || beneficial)
Let me see--
- OS-level web server
- NT codebase
- Microsoft
hmmmmm..... Perfectly expected. The first item is a major reason why I am avoiding Tux until either I can further test it or it has more real-world testing.... Although Tux runs on Linux, I have serious problems running server software which runs with that kind of machine access. I will stick with Apache running as Nobody....LedgerSMB: Open source Accounting/ERP
Hmmm.....
- Apache (at least 1.x) is a resource hog in Windows computers because of posix emulation among other things (and no shared memory).
- IIS is much faster on Windows than Apache (at least 1.x)
- Apache performs better on UNIX/Linux than on Windows
I can't see running this environment currently...LedgerSMB: Open source Accounting/ERP
Here is the accouncement for khttpd in June 1999. That's pre-2.4 if you didn't notice, the current kernel at the time of announcement was 2.2.9
Alan Cox wasn't sleeping, here is his 2c worth, about 2 weeks after the announcement. It's just a special in-kernel cache after all, not like running IE5 or IIS5 wholly in the kernel like some other OS's.
The home page is http://www.fenrus.demon.nl. kHTTPd only serves up static content, all non-static stuff is passed to a userland webserver, like Apache or Zues.
"Why didn't I join Microsoft? [LAUGHTER]"
Would a r00t exploit in the latest linux kernel make slashdots front page? I've often wondered this.
You sir are an idiot. Please click the links at your leisure.
Security Flaw with Linux 2.4 Kernel and IPTables
New Linux Worm
Linux 2.1.* Security Hole
*BSD procfs vulnerability Hey a BSD one!!
Linux 2.2 DoS Attack
IP Frag Exploit in Linux Kernel
New Linux Security Holes
Cracking All The Live Long Day & RH6/7
"Why didn't I join Microsoft? [LAUGHTER]"
There's been virtually billions of 'remote root' level holes in Sendmail alone, nevermind the various other daemons that ship with one or more standard Linux (and/or other UNIX based system) distributions..While these are reported on the geek/security sites like buqtraq, they rarely make it to the mainstream.
Anyway, this is bound to turn into a long useless series of Microsoft-sucks, Linux-sucks posts...But the reality is every OS, open source or closed, has major bugs found in it from time to time...glass houses..stones...etc. Try not to feed the trolls.
IIS is also far easier to install and maintain, it uses Microsoft's standard MMC console admin interface..Of course, there's two sides to the ease-of-admin issue (many will argue it invites security risk due to low-clue admins being able to do the job, half-assedly).
Probably the most important feature, though, is Active Server Pages functionality. The ability to write parsed HTML code in any of the languages supported by Microsoft's Active Scripting (JScript, VBScript, Perl, Python, etc), with the added bonus of access to pre-built COM objects.
It is quite nice. Personally, I prefer PHP for most web-app development..but the wide variety of language choice and the COM integration are pretty cool if you don't mind locking your box to Microsoft technology.
... Every new .0 release is generally pretty buggy. It's almost smarter to wait until .1 and .2 releases to upgrade.
Look at RedHat 7.0, for example. Don't bash MS because they have bugs -- to do that would be hypocritical.
Do you like German cars?
This wasn't caught during windows2000test!? I don't believe it!
No gaping holes in LInux?
Of course, the mad rush to upgrade to 2.2.16 was purely cosmetic, and had nothing to do with a root exploit affecting all the previous kernels of the 2.2 series.
And BIND has never had a serious exploit in it. Oh no.
[Note for the sarcasm impaired: That was sarcasm]
"Faith is the last resort of a desperate man" - Me
I think the development is easier & faster in IIS, e.g. using VB or C++ for distributed COM DLL's; or just using ASP pages with ADO or Oracle Objects for OLE. So right there is a big reason I know a lot of places like IIS.