Serious IIS Hole; Minor X Bug 477
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 goes to show... (Score:2, Interesting)
I honestly still think that some sort of un*x for idiots is needed before people will actually see open source opsys'es an alternative to bloody windows.
I can speak for myself, I'm a dumb windows-based webdesigner, and as much as I really like the idea of Linux, and the look of gnome and kde, and the coolness of using a console... you'd still have to dumb it down a bit more for me. Perhaps Apple's X... but then I hate Apple computers, it'd have to run on a PC.
Oh well, what I mean is: there's no point in comparing how much more terrible MSs bugs are and how much longer it takes for them to solve them. There has to be a real alternative to windows for the DUMB user, not for the tech-savy-geek, before people will actually say "hey, wait a minute, this is full of bugs and THAT over there isn't... I'll swap."
Just my opinion.
Moita Carrasco
What rubbish (Score:4, Interesting)
Re:Crashing X-Windows (Score:3, Interesting)
The Bugzilla report (http://bugzilla.mozilla.org/show_bug.cgi?id=15033 9) that the Register article links to has a couple of comments from Solaris users who say that the "malicious" page crashed their X server too. I don't know if Sun's X server and XFree86 are derived from a common code base, but this would suggest that the bug is (a) old and (b) widespread.
(The reason the Bugzilla link isn't a proper href is that I tried to check it just now, and Bugzilla said links from Slashdot aren't allowed. Make of that what you will!)
Re:This goes to show... (Score:5, Interesting)
I think you're wrong here, since Microsoft was always very, very good at feeling out the vibes of their customer base. The current perception in the marketplace is, that Microsofts security is beyond rotten. Since even the Gartner Group [gartner.com] got on the bandwaggon, Microsoft seems to be scared shitless about that public perception.
The problem is the same as the sorcerers apprentice, who just can't get rid of the monsters anymore.
For years and years Microsoft has (overladden-) their products with features and bloat. They missed the internet entirely and when they realised their mistake they rushed an inherently insecure internet platform into the market and during all this time they didn't give a flying f*ck about security.
I agree, that Microsoft is an extremely arrogant company, that regards their customer base as cows to be milked and taken for a ride in every way possible.
The problem is that perception is changing and so they are frantically trying to restore trust; they can't let such glitches happen by purpose.
I think it's too late though to call the monsters back in and even worse:
It is my true conviction that any IT responsible on any level using IIS on new projects is guilty of gross negligence and incredible incompetence.
Three days? Rather a bit longer.... (Score:5, Interesting)
I am pretty sure this bug has been in Bugzilla for months without being fixed. However, bugzilla-search seems to be broken so I cannot prove it right now.
However, I am 100% positive I crashed my machine due to a remotely exploitable X bug using Mozilla a few months back. That bug is in bugzilla (search on crash, X, css, hensema when bugzilla search works again).
Re:Serious Linux Flaw? (Score:3, Interesting)
Failing that (and I agree that it would be hard to come up with a sensible limit), I believe that you can enable kernel-level process accounting, whereby such things are enforced strictly by the kernel on a cumulative basis - ie each user gets an allocation of CPU time and memory. How they use that is up to them, but once they exhaust it, they can't have any more. I may be wrong, though - that may just be for logging their usage, for "charge-per-use" schemes.
In any case, the best that the memory manager could possibly do is reserve some percentage of the available memory for root, as is done with hard drive space. Of course, as X runs as root, (and has to in order to access the hardware, iirc) that wouldn't help. I'm not really very well versed with the internals of the Linux kernel, but I suspect that the memory manager "just" manages requests for memory, without regard to whether those requests are sensible. There's only so much a system can do to protect itself from malicious or badly written code that is running on it.
Cheers,
Tim
Re:I already view large fonts. (Score:1, Interesting)
Re:Only affects HTR - a rarely used feature (Score:2, Interesting)
I know this is a GNU/Linux/OSS advocacy site. I have a great deal of appreciation for Linux, not because I use it on a daily basis, but because it is forcing my OS vendor of choice to at least pretend to sit up, take notice, and focus on some things the market never forced them to focus on before.
I know. I done been trolled.
It is really an X11 bug (Score:2, Interesting)
allocate because they don't know how much they would
use. Kernel overcommits because it expects apps to
over allocate. If kernel wouldn't over commit then
you would require absurd amounts of Swap to run.
X11 is a special app, because if it dies the screen
dies and you can't interact with the system although the system might be functioning fine.
What happens in this case is that the X11 is
killed promptly by the kernel, and does not get
any time to restore the console. Kernel cannot
and must not differentiate between processes.
In this case though the problem is more clear cut
X11 must not allow absurdly large fonts. There
should be a limit to the size of the memory it is
allocating based on the system memory. So that
it doesn't put itself into danger. It might be a
difficult question in different settings but this
case just requires a upper limit on font size,
based on the display size and system memory.
-anand
Re:Serious Linux Flaw? (Score:3, Interesting)
Your machine "locks" exactly because XFree86 (or other X implementation) is killed by the kernel for consuming too much memory (the "infamous" OOMKiller). Try: and you'll see your machine locking exactly like in the DoS described.
The reason it happens is that XFree86 is controling all video hardware (registers, memory...) and when you force it to die, it can't set the hardware back to the default/previous (console) values.
You still can log remotely and reboot your machine, of course, but forget about keyboard, mouse and video.
--
sig
How easy is it to r00t, with a heap overflow? (Score:1, Interesting)
If you've got a buffer overflow on the stack, it's trivial to clobber the stack frame pointer, and therefore the return address, and have the CPU jump into the middle of your buffer for the next instruction. *BUT* if all you can do is write into the heap, how do you ever convince the CPU to jump to your buffer and execute it?
In the special case that you knew the position of a function pointer, I could see how you'd go about it, but is there a general technique to exploit this sort of thing? If not, then I think people are getting a bit more hyped up about this than is warranted.
Listen kids, this was a known bug before BugTraq (Score:3, Interesting)
Basicly it's not just CSS it's also mixtures of center and header tags that are NOT escaped. I ran into the bug on a poorly done eBay user home page with code like:
The bug is Mozilla (gecko) doesn't parse this very well, and causes the font to scale larger and larger. This in turn allocates more and more main memory until your poor box runs out.
From our tests on #mozilla:
My linux 2.4.16/gdm/XFree 4.x box only crashed X.
A BSD user with experimental video drivers had his machine reboot.
Several other linux users ( 2.4 ) only had X crash.
One linux user with > 1GB of RAM had no effect b/c his session was too short to fill all that. =)
In short this was reported and being worked on before Mozilla 1.0 was even out.
Here's the bug report kindly filed by #mozilla:
http://bugzilla.mozilla.org/show_bug.c
Here's what I can't figure out (Score:4, Interesting)
You have all the code. It shouldn't be too hard to find the few places that you need to cap font size.
Where's all the programmers?
Re:Only affects HTR - a rarely used feature (Score:3, Interesting)
I know your pain, as do many others. It's been said that IT groups don't choose Microsoft products, they just install them. One workplace of mine has Exchange, IIS and all the MS side-dishes, and I fought them kicking and screaming. But, the marketing geeks upstairs read in a magazine that something is a "robust solution" and assume it'll work in our environment.
Of course, I'd rather spend my day implementing cool new stuff to make their work better, but instead I sit around coddling a patch-monster.
Re:Incorrect ! (Score:4, Interesting)
As pointed out in several posts to Bugtraq, yes, the actual bug is in X (probably in libXfont) but Mozilla is a program that retrieves untrusted data across a network and, as such, has a responsibility to reject or sanitize data that could cause problems. The old Internet maxim is, "Be liberal in what you accept and conservative in what you send," but that doesn't mean you shouldn't also do some sanity checking.
--Phil (Ardent Bugtraq follower.)