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.

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.

Slackware is still safe...

[unixmaster]

Slackware doesnt use xfs font server so that mozilla doesnt crash when viewing big ( really big ) fonts .

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 [mozilla.org]

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.

Clarity on te Moz / "Linux" bug

[bshuttleworth]

The bug is a general one, related to how X deals with fonts. This can be verified by reading the Bugzilla discussion - which I won't link to from here - last thing Bugzilla needs is 100k people going "ooooooooh... a bug" and inducing a slashdot-style-DOS;) - where they verify a similar problem with Sun's X server.

That Mozilla can made to induce this does make Mozilla a critical problem - a malicious page can cause any desktop to crash using it. That it is not the "cause" of the problem is only a matter of semantics.

And of course, the fix is already in, specifying that fonts are no larger than twice the display height.

Find your way to bugzilla via the Register [theregister.co.uk]
for enlightenment ;)

Re:What rubbish

[m0i]

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

Re:Crashing X-Windows

[int0x80]

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.

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

[Henry Stern]

FYI: MS uses smaller teams (15-20 IIRC) of programmers.

read the report

[Anonymous Coward]

on trustworthy computing [trustworthycomputing.com], submitdead buy the Penguin de Linusville Institute.

can a scruffly beard be far behind? will it help with the BiG ?pr? poosh?

Re:Crashing X-Windows

[orkysoft]

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.

The IIS bug is _not_ that bad

[Craig Ringer]

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.

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.

Re:Status Quo

[Anonymous Coward]

Hey troll. IIS != OS.

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:Status Quo

[Anonymous Coward]

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.

Re:New MSN.com homepage code

[Anonymous Coward]

if (stristr(HTTP_USER_AGENT,'mozilla')){
echo '16666666666';
} else {
echo '12';
}

Hmm...
*takes a look at his HTTP_USER_AGENT*
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)

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

[Erik Hensema]

Found it: bug 120238 [mozilla.org] is the bug I remembered, it was filed 2002-01-16 and still stands unresolved (IOW it has beem ignored). Worse still, bug 90547 [mozilla.org] 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.