Slashdot Mirror
Serious IIS Hole; Minor X Bug
EyesWideOpen writes "Microsoft announced Wednesday that there is a serious software flaw with its IIS web server. The 'vulnerability affects a function in the server software that allows Web administrators to change passwords for an Internet site.' A researcher with eEye Digital Security discovered the flaw in mid-April but it wasn't announced publicly because of an agreement with Microsoft. The Wired article is here and this appears to be the MS bulletin describing the vulnerability in detail." And several people reported this Register story on a way to DOS Mozilla users by trying to display ludicrously large fonts. Microsoft's time to patch a remote hole where the attacker can gain complete access to your computer: two months. Open Source's time to patch a much less serious bug where the attacker can merely crash your computer: three days.
This is hardly a major bug IMHO... "an older, largely obsolete scripting technology - where the previous one lay in the ISAPI extension that implements ASP." "The IIS Lockdown Tool disables this functionality by default. Customers who have retained the functionality but deployed the URLScan tool as discussed in Microsoft Security Bulletin MS02-018 would likewise be protected against the vulnerability." So, it only really affects those sysadmins who don't bother to lock their server down. It's not going to be a major issue for the majority.
Join the Free Software Foundation
and
Slackware doesnt use xfs font server so that mozilla doesnt crash when viewing big ( really big ) fonts .
Never learn by your mistakes, if you do you may never dare to try again
You can use the ulimit command to set an upper limit on the memory available to any process started by the shell under which it is issued.
Just putting something like ulimit -m 200000 in your startx script should limit X's memory usage to 200meg.
ulmit can also set upper limits on available CPU time, core file size, etc. Bash has a builtin version, so do man bash and look for ulimit for more details.
It's official. Most of you are morons.
The exploit asks for a font that's utterly ridiculous - a 166666667 size font, give or take a few 6's. Mozilla tries to get X to display such a font. X dutifilly attempts to draw at that size, which requires a tremendous amount of memory, eventually bringing the whole machine down. You could get the same result by putting a malloc or fork call in a while(1) loop.
I personally think Mozilla should implement some short-term patch to prevent exploitation of this bug until it's patched in XFree, but as the register article says, the fault doesn't lie with them.
They already did. It's obviously a trivial fix - no fonts larger than 1,000 (or whatever). I'm suprised it took that long.
I've also found that the screen calibration thingy on the fonts preferences (select 'Other..' under 'Display Resolution') makes a big difference too.
Checkout the bugzila item here
Also, this is _not_ a DOS attack. What it does is make X consume all available memory and swap. And it can be triggered remotely by running mozilla, and browsing a webpage with absurdly large fonts. But it is by no means a DOS attack, because no-one is actively attacking you, making you "Deny Service" to other users.
Debian doesn't even have the newest XFree86 revision in it, so where am I going to get the patch for this
Debian backports security patches to whatever version they provide; look at their apache 1.3.9, it obviously doesn't have all the security bugs fixed up to the latest build..
have you been defaced today?
For someone who was brave enough to try the crashing link supplied by the Register, does this kill the whole machine, or just X? And can you salvage things without rebooting by using either a virtual term or logging in via ssh?
Yes, linux doesn't crash :-) You can still access through telnet/ssh. You can't switch to a virtual terminal, though.
Order is for idiots, geniuses can handle chaos!
Apparently it's an X bug which can crash the GIMP and others as well -- only reason mozilla's special is that you can exploit it remotely.
Ctl-Alt-Backspace if you get hit with it, and reboot your X-server. If you want a bit more protection, run XFS font server separately (rather than letting X handle fonts) then only the font server will crash.
As for "time to fix", well XFree86 has been out for a while now, so presumably it was vulnerable all along.
FYI: MS uses smaller teams (15-20 IIRC) of programmers.
can a scruffly beard be far behind? will it help with the BiG ?pr? poosh?
It doesn't have to do as much with C programming as it has to do with memory management implementation:
Since we all have "virtual memory" nowadays, it is entirely possible that a malloc() call reserves pages of memory that are only physically allocated once you use them. Whether or not this happens depends on your kernel's memory manager.
I suffer from attention surplus disorder.
It's a heap overrun. Very hard to exploit to exec custom code, all you can really do is crash the server. Not that that's a good thing... interesting to see that IIS5 auto-restarts too (so that an attacker can compromise the binary then crash the server so it re-loads?)
MS actually _overplays_ this one in the release. For once. Too bad they claim its newly discovered.
OTOH the moz bug is (a) not in mozilla but in X as mentioned elsewhere, (b) not really fixed, just workarounded in mozilla and (c) A TOTALLY DIFFERENT ISSUE.
OTOH the IIS bug was an overrun and would be a 5min patch.
I don't believe that MS does so much testing for their patches. I heared enough about MS patches not fixing the bug/hole it's supposed to, causing new problems, or not play well with some applications (i.e. causing them to crash). How can that happen if MS did all that testing you describe? Also i really wonder why it should take two weeks to put a patch on a webserver and write a brief documentation about it, especially since they've enough time to put together documentation while doing internal testing (they need that anyway for customer testing).
And while some (unsure about the percentage) mozilla fixes cause regression, they often hit the nail on the head with the first patch. In that ideal case the bug is squished within 3 days. Even if your "schedule" for mozilla fixes were correct, the mozilla developpers can do four iterations of that in the six weeks time it takes MS to issue their first patch. Then you assume that usually MS get's the fix right the first time, but if they don't and find regression after one week of internal testing they have to iterate too until they get it right and it'd be about as fast as an iteration in the mozilla case. If they catch it in the first week of "customer testing" they need 3.5 weeks for a cycle.
The advantage of the mozilla strategy is, that as soon as the patch is ready, anyone can test it (and at least the big linux distributions probably do so), and if there is a problem with a patch, information gets back to the developpers much earlier.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Hey troll. IIS != OS.
As for the HTR, anybody that does a "typical" install (i.e. just selecting default options) of a Web server has larger problems than their OS.
"Da ist ein Technölüst in mein Unterpanten!"
As for "time to fix", well XFree86 has been out for a while now, so presumably it was vulnerable all along.
And you're implying that IIS has only been available since mid-April?
The "time to fix" is the time from when the vendor is notified until they produce a patch.
*takes a look at his HTTP_USER_AGENT*
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Found it: bug 120238 is the bug I remembered, it was filed 2002-01-16 and still stands unresolved (IOW it has beem ignored). Worse still, bug 90547 also reports a crash due to large fonts. It was reported around 2001-07-12, which is 11 months ago.
This is your sig. There are thousands more, but this one is yours.
[Not that it's clear that the IIS bug is really a remote access bug (see above where it's explained as a DOS bug) but there have been plenty of remote access IIS bugs (see Code Red).]
The X bug only crashes your machine if you browse to a malicious web site. The malicious person can't do anything to your machine if they can't induce you to go to their web site, and the effect on your machine of visiting the web site is immediately obvious (X and possibly your whole box crashes) so you can learn not to visit that web site again. The malicious user doesn't really gain anything other than the jollies of knowing they crashed some machine.
A remote access bug allows someone to take over your machine surreptitiously, which is much, much worse than just crashing your machine. It means your machine's data can be inspected and changed without your knowledge, and also that your machine can be used as a staging point for other illegal activities. Particularly if your data is sensitive, this provides a great deal more incentive to a malicious user.
This is a fabulous example of something that still sucks mightily about X, and shows no signs of being fixed. Ok, how a real font system would render a 500 foot tall 'A':
send the 'A' glyph, along with whatever hinting it needs for 'insanely, off the scale big' (i.e. probably the hint for the biggest glyph it defines, like 72 pt). The renderer takes the 'A' and converts it into a series of strokes. The strokes are then rendered into the clipped region, resulting in pretty instantaneous drawing. The font manager decides wisely that this rendered glyph, being "pretty big", shouldn't get cached as a bitmap the next time you want to draw it.
Here's how X does it:
Request the font for the 'A' glyph, scaled to 500 feet tall. Construct an uncompressed 1bpp bitmap of the letter A to give to X to blindly blit onto the screen. Die a miserable thrashing death.
I've finally had it: until slashdot gets article moderation, I am not coming back.