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.

Comments

Only affects HTR - a rarely used feature

[byolinux]

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.

Incorrect !

[dnaumov]

This article is incorrect. That bug is an XFRee bug and not a Mozilla bug. It's not fixed, although it's possible that it's been worked around in Mozilla. Read the text itself, I think it says:

X-windows, with or without the font server (XFS) running can be crashed remotely via Mozilla when fonts are set to an unnaturally large size with CSS (Cascading Style Sheets), Tom Vogt of Lemuira.org has reported.

and

"An X bug allows all available memory to be consumed, which causes the system to freeze. The behavior can be duplicated with applications like the Gimp, we're told, but these aren't remotely exploitable. But with Mozilla, a pest can easily set up a malicious Web site which will crash unsuspecting Tuxers' boxen and cause any unsaved data in open apps to go away.

Re:Serious Linux Flaw?

[Tim C]

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.

Re:Crashing X-Windows

[RandomPeon]

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.

Re:I already view large fonts.

[uglyduckling]

If you look in the 'fonts' preferences, there's now an option for minimum font size. It's a great way to deal with ridiculously small fonts without making everything else look chubby.

I've also found that the screen calibration thingy on the fonts preferences (select 'Other..' under 'Display Resolution') makes a big difference too.

This is _not_ a bug in mozilla

[theridersofrohan]

This is a bug in XFree86 and/or (depending on what you are using) XFS. The error doesn't happen under windows... And apparently, it can be triggered under linux by other programs as well (gimp) if you set the font size absurdly high.

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.

Re:Status Quo

[peddrenth]

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.

Re:Flawed logic

[gotan]

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.

Depends on the OEM

[TechnoLust]

If you are talking about the IIS feature in Win2k, this is only installed by default on CERTAIN OEMs. For example, Dell desktops with Win2k preinstalled do NOT have IIS installed. In cases where it is preinstalled, that's the OEMs fault, not MS. If RedHat or Susie had an option to install a trojan and some users were dumb enough to do it, would you blame them? Or the stupid users? If you blamed the users, would you then say all Linux users were idiots because some of them did a terrible install job? Then why does it work that way for Windows users? I just don't understand the double standard. I use Windows and Mandrake Linux, and both have their strengths and weaknesses.

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.

Re:Three days? Rather a bit longer....

[Erik Hensema]

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.

There's a huge difference

[mmacdona86]

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

The Font That Ate Cleveland

[scrytch]

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.