Forgot your password?
typodupeerror
Bug

Serious IIS Hole; Minor X Bug 477

Posted by michael
from the truthworthy-computing dept.
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 discussion has been archived. No new comments can be posted.

Serious IIS Hole; Minor X Bug

Comments Filter:
  • To me that's one of the benifits of Mozilla. I view everything at 120%. Take that CNN! You can't stop me from actually reading stories now.
  • Status Quo (Score:2, Funny)

    by Johnny O (22313)
    About Status quo in M$ land....
    About Status quo in Linux land :-)
    • Re:Status Quo (Score:4, Insightful)

      by GypC (7592) on Thursday June 13, 2002 @05:03AM (#3692418) Homepage Journal

      It's not a Linux bug, but rather an XFree86 and mozilla bug. It would probably crash any box running those two programs just as handily...

      • Re:Status Quo (Score:4, Informative)

        by peddrenth (575761) on Thursday June 13, 2002 @05:52AM (#3692538) Homepage
        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.
  • by Xpilot (117961) on Thursday June 13, 2002 @04:15AM (#3692302) Homepage

    Wow, I didn't know that Mozilla had a DOS version! How many users does it have? Three?
  • by byolinux (535260) on Thursday June 13, 2002 @04:16AM (#3692304) Journal
    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.
    • by erlando (88533) on Thursday June 13, 2002 @04:23AM (#3692330) Homepage
      But you are forgetting the vast amount of users running IIS without knowing it by way of having installed Win2K with indexing services and what not.

      The majority of Code Red attacks came (and is still coming) from private users that have never even heard of a Microsoft Security Bulletin, the URLScan tool or the Lockdown Tool.

      Sadly these type of users are still in the majority.

      • by Sycle (569193) on Thursday June 13, 2002 @06:21AM (#3692597)
        If people don't apply patches, fixes, updates and security recommendations, then Microsoft could have released a fix in 2 seconds, and it still won't do any good.

        Linux and other open source software aren't impervious to bugs being discovered either, they just respond faster - so the lesson here is simply "if you're an idiot, you can get '0wn3d' on any OS".

        Yeah it sucks that Microsoft take two months to fix an exploit, but if it only affects a service that would have been switched off already if you followed instructions, then it's not *that* big of a deal.
      • Sadly these type of users are still in the majority.

        very true. if Microsoft wish to market a product that is supposedly easy to use and administer, it is not the user's fault for not being told to patch and upgrade constantly.

        i'd be the last person to stand up for Microsoft, but a lot of the problem is in the fact that novice users are fooled into thinking they can sysadmin without experience and training, and NOT because the software is deficient. almost any other OS you'd care to mention is vulnerable out of the box, but they are usually aimed at people who know what they are doing and patch them accordingly.

        Microsoft design and market their server OSs in a way that makes it look like any fool off the street can administer them, and in my experience that is usually the case.
    • by edrugtrader (442064) on Thursday June 13, 2002 @05:04AM (#3692419) Homepage
      "this really affects those [microsoft] sysadmins who don't bother to lock their server down"...

      ...right... so EVERYONE is affected... hardly a major bug at all.
    • I know. Any decent admin disabled the .htr filters what... two years ago? three?

      Well, it helped me wake up this morning.
  • Incorrect ! (Score:5, Informative)

    by dnaumov (453672) on Thursday June 13, 2002 @04:17AM (#3692307)
    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.
    • "An X bug allows all available memory to be consumed, which causes the system to freeze."

      Why on earth would that happen, unless your kernel VM was seriously screwed? Last time I saw any one process hog all the RAM, it got killed pretty sharpish.

      There's also a call in the bugtraq thread for apps to be more sensitive about the data they get back from calls into external APIs. That makes sense to me - especially when anyone can LD_PRELOAD a library with broken return values for various functions.

      Well spotted mozilla, now everyone *else* get your acts together please ;)
    • "That bug is an XFRee bug and not a Mozilla bug"

      Well, the Mozilla "bug" is that Mozilla doesn't perform a check to see if the font size is sane, it just blindly tells X to show an extremely large text. But X should definately check that it can handle it itself, so the bug is an X bug, Mozilla should just be a little more friendlier with X :-)
    • It's unclear what versions of X are affected. The reporter claims to have verified the bug with 4.2.0, but on my box with XFree 4.1.0, all that happens is Mozilla closes down immediately. The Gimp does the same. No memory problems. (Still a bug, but definately not the DoS attack it's made out to be)

      So it probably only affects XFree 4.2... I don't have 4.2 installed to verify.
      • Long ago I managed to open up waaaaay too much with The Gimp and it clearly sucked up my system resources to the point where I could do nothing to kill it. I could log in remotely, but even from a remote shell I couldn't get the system to shut down except through a dirty "shutdown -f". I don't know if it's a similar problem or not. The article states that there was no means to kill X from the main box, but nothing was stated about going in remotely.
    • by ActiveSX (301342)
      An X bug allows all available memory to be consumed

      All these years and I thought X was supposed to do that. Silly me!
    • A fix was checked into the Mozilla trunk yesterday so it'll probably go into the 1.0.1 branch once approval is given. Mozilla restricts the max font size to 2 times the screen height.
    • by Per Abrahamsen (1397) on Thursday June 13, 2002 @06:19AM (#3692592) Homepage
      Most applications will attemnpt to allocate sufficient memory to handle the task the user assign to it, and depend on the system to refuse the request if there are not enough memory. They then handle the refusal with warying amount of grace. It should not crash the OS, unless the OS itself is broken.

      For example, if you feed GCC with ridiculous large input, GCC will (attempt) to allocate ridiculous amount of memory. Which is how it should be, the applications should not try to second guess the user.

      Applications that take data from untrusted sources, like web browsers, should course make sanity checks. So the error is in Mozilla, not X11.

      Nonetheless, one can expect more from a desktop server like X11 than from more traditional applications, since if the desktop crash all the user visible applications will go with it. So it would be a reasonable feature for X11 to make more sanity checks on its input than other local programs do.

      • by anandsr (148302)
        Its a very difficult problem. Applications do over
        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
        • In this case though the problem is more clear cut
          X11 must not allow absurdly large fonts.


          And if I'm working in the Gimp, and am trying to create a 40,000 pixel-tall letter A? The X Font Server should fail to allocate the memory to render my character why?

          No, I think the fix has to be in Mozilla. When a desktop user really wants an insane font-size, they should be allowed to have it.
        • by CaseyB (1105) on Thursday June 13, 2002 @08:14AM (#3693035)
          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.

          Hardly. Hasn't everyone at some point telnetted to a *nix machine to kill and restart a hung X11 process?

      • Applications that take data from untrusted sources, like web browsers, should course make sanity checks. So the error is in Mozilla, not X11.

        They should in some, but not all, cases. That's why rlimits exists. Certain classes of applications should not have to check everything for themselves. For example, the qmail SMTP server can be made to allocate an arbitrary amount of memory by feeding it a huge list of recipients. This is not a bug. It is designed to be run with resource limits, usually set using softlimit. It is bad engineering to include needless checks in every single application, when the OS has this built in.
    • Re:Incorrect ! (Score:4, Interesting)

      by Phil Gregory (1042) <phil_g+slashdot@pobox.com> on Thursday June 13, 2002 @10:25AM (#3693910) Homepage

      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.)
  • The fact is Microsoft doesn't give a damn, because it doesn't need to give a damn anymore. Windows in its various forms continues to have outrageous security holes, and still people keep using it, buying licences and standing by it.

    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
    • by CaptainZapp (182233) on Thursday June 13, 2002 @04:47AM (#3692375) Homepage
      The fact is Microsoft doesn't give a damn, because it doesn't need to give a damn anymore. Windows in its various forms continues to have outrageous security holes [...]

      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.

  • I'd heard briefly about the Mozilla bug, and I understand why it's X's fault, but I'm curious... how is it that X is able to crash the system this hard? Because it's got direct access to hardware? Because it runs with root privledges? Also, is this just XFree86, or are all variations of X affected?

    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?

    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.
    • by Pembers (250842)
      Also, is this just XFree86, or are all variations of X affected?

      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!)

    • by RandomPeon (230002)
      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.
      • by AstroPup (266218)

        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.


        Big whoop. Apples and Oranges. I can think of several way I can crash or lock up my machine. The Mozilla bug
        is a remote exploit. It's an easy one. There has to be a Mozilla bug that allowed someone to cause an endless fork on my machine to be equivalent. It's not about what you can do to your box, it's about what folks you don't want crashing your box can do.
    • What I don't understand is why the story said simply there was a bug in Mozilla; if it's xfree, then people using Mozilla on Windows aren't effected, eh?
    • by int0x80 (234172)

      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.

      • You can't switch to a virtual terminal, though.

        That's because X still has control of the keyboard, and so the system cannot respond to your keypresses.

        9 times out of 10, though, when X crashes (which is infrequent), I can ssh in from a friend's machine and kill it off. It's a bit of a pain, but as a programmer I realise that no software of even moderate complexity can ever be 100% bug free, especially something as large as X, that is used in such a wide variety of situations and on so many different types of hardware.

        Cheers,

        Tim
  • Slackware doesnt use xfs font server so that mozilla doesnt crash when viewing big ( really big ) fonts .
  • What rubbish (Score:4, Interesting)

    by johnburton (21870) <johnb@jbmail.com> on Thursday June 13, 2002 @04:23AM (#3692329) Homepage
    The X bug is very serious. It's possible to set up a web site that will cause any X based computer looking at it to crash. But it's not a microsoft product so I expect the majority of people here will just ignore it and carry on bashing microsoft products as usual.
    • Re:What rubbish (Score:5, Insightful)

      by krmt (91422) <therefrmhere@@@yahoo...com> on Thursday June 13, 2002 @04:42AM (#3692364) Homepage
      I agree that the X bug is very serious (and I'm particularly worried about it because Debian doesn't even have the newest XFree86 revision in it, so where am I going to get the patch for this) but there is a difference in terms of the problem.

      This is a lot easier to exploit for the malicious hacker than the IIS bug. You just set up a page with huge fonts and that it, you've crashed X. But the payoff for that is a laugh at the (relatively) rare X user who visits your site.

      As for the IIS bug, I'll just quote the Wired article...
      Microsoft acknowledged a serious flaw Wednesday in its Internet server software that could allow sophisticated hackers to seize control of websites, steal information and use vulnerable computers to attack others online.
      This, in my opinion, is a lot worse than simply crashing X. Hell, my Windows 98 crashes almost daily but that doesn't stop me from using it. Crashing isn't so bad. Black Hats stealing information and gaining control of my computer, that's bad.
      • Re:What rubbish (Score:2, Informative)

        by m0i (192134)
        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:What rubbish (Score:3, Insightful)

      by Rogerborg (306625)
      • The X bug is very serious. It's possible to set up a web site that will cause any X based computer looking at it to crash

      "Any"? Spurious assertion. I've just viewed the test site, and didn't get a crash. Mind you, I only tried Konqueror, Eudora and lynx. Should I keep trying all of the other browsers that I have available until one manages to achieve the specified behaviour, or should I go back to worrying about my work machine (NT4, mandatory and unpatched IE5.01 & Outlook Express) getting rooted out from under me?

      You're right that we do bash Microsoft products more than they deserve. But not much more. I'd prefer if we bashed the clueless Microserfs and control freakish IT departments that tolerate and encourage this horridly vulnerable monoculture, but that's a separate debate.

  • by taliver (174409)
    Isn't this X bug a symptom of a more serious linux bug? Why should any process get to take all of the memory. I've done this with strictly user level programs, and I was able to make the system crash (a severe memory leak in a small program I had written). How should any user level process stop a machine?

    In a couple of cases, Linux was able to kill my memory hog, but there's some sort of serious resource contention. I hope the 2.6 kernel addresses this issue.
    • by Tim C (15259) on Thursday June 13, 2002 @04:38AM (#3692358)
      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.
      • by asr_br (143523)
        No. ulimit is not going to work for that case.

        Your machine "locks" exactly because XFree86 (or other X implementation) is killed by the kernel for consuming too much memory (the "infamous" OOMKiller). Try:
        kill -9 `pidof X`
        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
  • by Anonymous Coward on Thursday June 13, 2002 @04:27AM (#3692338)
    It can hardly be just to compare the two software bugs where one is a web server and one a internet browser. That's like comparing getting rid of pollution to getting rid of bad breath.

    And also I'm surprised about the stupidity in this sentance: "Open Source's time to patch a much less serious bug where the attacker can merely crash your computer: three days." - well honestly, what does that say: isn't it obvious that a lesser problem takes less time to fix than a larger one? That's just dumb.

    I'm no huge M$ fan myself, but this article smells awfully much of unjustified M$-hatred. Let products speak for themselves, and let users make their own opinions.

    Bottom line: propaganda sucks.
  • Flawed logic (Score:4, Insightful)

    by rufusdufus (450462) on Thursday June 13, 2002 @04:28AM (#3692339)
    The author says that it took Microsoft two months to fix a big flaw in IIS, while it took open source only three days to fix a little flaw in Mozilla.
    This comparison defies rational comprehension. The length of time it takes to do two totally different tasks on two totally different pieces of sofware for two totally different markets is completely meaningless. I can write a program and pop it onto internet in an hour...so what? Whats the relationship?
    • Re:Flawed logic (Score:4, Insightful)

      by uglyduckling (103926) on Thursday June 13, 2002 @04:56AM (#3692398) Homepage
      MS has armies of well paid programmers who know the software inside out, is in the middle/end of an apparently unilateral security review, and has taken two months to patch a hole in their flagship web server product.

      Mozilla has - well perhaps a relatively small army of programmers, many of whom are voluntary, and managed to patch a bug that is really only a pain in three days.

      Yes - you can't quantatively compare the two and say that Mozilla is x percent more efficient/reliable/whatever than MS, but you can make a qualitative comparison and ask why MS took an order of magnitude longer time to respond. Even if we give MS the benefit of the doubt and assume that the IIS hole is much harder to patch than the Moz hole, MS should have and could have thrown much more resources at the problem to make sure it got fixed within a week - but they didn't.

      • Re:Flawed logic (Score:4, Insightful)

        by dregs (24578) on Thursday June 13, 2002 @05:49AM (#3692533)
        The core point is how long did it take to test the fix, Many, Many Mozilla fixes cause regressions elsewhere.

        In General (i.e. not these particular problems)

        I'd bet the MS had the fix inside three days as well, it then took (At a guess)

        2 weeks for internal regression testing
        4 weeks for external large scale customer testing and feedback
        2 weeks to get the documentation, patches and everything out for wide scale deployment.

        All in all thats pretty fast.

        With Mozilla I'd say

        3 days to fix
        1 day to apply fix
        3 - 5 days to get a testers to try the nightly build
        numerous days of people complaining about fix
        1 day * 3 as patch is removed
        1 day as patch is reaplied

        etc
        you get the idea
        (I have used Mozilla for the last 12 months on a daly basis, so don't think this is a Mozilla b
        • Re:Flawed logic (Score:4, Informative)

          by gotan (60103) on Thursday June 13, 2002 @07:16AM (#3692781) Homepage
          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.
          • [Microsoft patches occasionally do] not play well with some applications (i.e. causing them to crash)

            That's not a bug, its a feature! After all, we wouldn't want you to accidentally use that horrible Trillian or Jabber instead of MSN Messenger, would we? That could ruin your Windows Experience(TM)!

      • Re:Flawed logic (Score:2, Informative)

        by Henry Stern (30869)
        FYI: MS uses smaller teams (15-20 IIRC) of programmers.
      • by Otis_INF (130595) on Thursday June 13, 2002 @06:12AM (#3692577) Homepage
        .HTR is a flawed protocol and should be avoided. No sane developer will use .HTR pages in his site on an IIS machine, since the .HTR parser is crappier than crap since day one with buffer overruns all over the place. Most sysadmins have .HTR disabled anyway, since it's of no use. When there is a bug in that parser, thus _NOT IN IIS!_ but in an extension (like mod_perl to apache), and that parser is not used by a lot of people, would you put a lot of developers on that bug? No.
        • I agree with you, and was pleased to discover that none of my boxes were vulnerable. Nonetheless, as we know, most IIS boxes out there are still in their default configuration and a good number of their admins don't even know they're running. Each one of these boxes is a potential DDOS client.
        • You gotta be kidding, I didn't notice that the articles specified that only .HTR pages were affected. I have those disabled for quiet some time now. Who exactly uses .HTR?
  • OK, is anyone else sick of the inane way in which we compliment ourselves continuously?

    Come on, we really do not need to say these sort of things nah nah, we fixed something first, we're better than you. Does anyone else find it retarted that you can crash an X server just by telling it to display a font which is too big?

    What about the fact that we STILL don't really take advantage of gfx hardware for 2D presentation? or the fact that fonts still look like ass?

    If you think we can laugh at others, check those market share figures. We have a lot of work to do.
    • Not me. (Score:5, Insightful)

      by Per Abrahamsen (1397) on Thursday June 13, 2002 @06:04AM (#3692558) Homepage
      Slashdot is and has always been an advocacy site, and has never prentended to be anything else.

      It presents the GNU/Linux and free software side, which is a small step towards bringing balance, as we do not have the big advertisement budgets to buy editorial good will, or money to order favorable rewievs from "the customer is always right" analysis companies.

      What I am getting tired of is the the people who whine that slashdot is not Ars Technica [arstechnica.com] or kuro5hin [kuro5hin.org], both excellent web places with a different focus than slahsdot.

      What about the fact that we STILL don't really take advantage of gfx hardware for 2D presentation?
      What do you mean "we", white man? I have "taken advantage of" 2D gfx hardware under Unix for longer than slashdot (or Linux) has existed.

      or the fact that fonts still look like ass?
      They fonts don't look "like ass" on my screen. I guess what you want is anti-aliasing. The free technology for that is awailable, it is just a question of installing it. Maybe your OS distributor have done it for you in a sufficiently recent version.
    • by JMZero (449047) on Thursday June 13, 2002 @09:42AM (#3693599) Homepage
      How come nobody is posting a quick source patch? WTF? Isn't that one of the great things about open source?

      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?
  • Ummm ... so what? (Score:3, Insightful)

    by Mr_Silver (213637) on Thursday June 13, 2002 @04:47AM (#3692374)
    Time for my neighbour to fix the dodgy shed door: 2 months. Time for me to fix the dodgy wiring in the kettle: 15 minutes.

    Not wanting to be pedantic but the duration of time it takes to fix a bug isn't exactly a great indicator of anything (except maybe, how long it took to fix it).

    It's a bit like assuming that a program with 5000 lines is obviously worse than one with 7500 lines.

    We know nothing about the internals of IIS and the two bugs are not even remotely related. You simply can't compare the two and come out with anything meaningful.

  • In which context do you consider it a minor bug, if the XFree tries to scale it's font any size you determine? Memory-hog bugs are never minor (just see Microsoft Windows for reference ;)) - I mean this can also be an indicator of some even more serious mis-think on checks that are done to Xfree fonts before trying to display them. I would not be surprised if in 2 weeks there was an article on securityfocus stating "displaying 'gimme root' in supersize fonts in Xfree environment provides the intruder with remote root exploit."
  • by SeanTobin (138474) <.moc.liamtoh. .ta. .rtnuhdryb.> on Thursday June 13, 2002 @04:48AM (#3692381)
    <body>
    <font size=<?php
    if (stristr(HTTP_USER_AGENT,'mozilla')){
    echo '16666666666';
    } else {
    echo '12';
    }
    ?> >
    Welcome to the new MSN.COM website, powered by the .NET framework....

    (sorry about the previous post... previewed ok, but didn't post correct without extrans...)
  • by WasterDave (20047) <davepNO@SPAMzedkep.com> on Thursday June 13, 2002 @05:09AM (#3692440)
    It strikes me that there might be some quite serious money in these "agreements with Microsoft". In a post dotcom world, it's a pretty plausible business plan:

    * Find holes in MS software.
    * Publicise them frantically.
    * Come to "an agreement".
    * Kachingggggg!

    Dave
  • by theridersofrohan (241712) on Thursday June 13, 2002 @05:10AM (#3692444) Homepage
    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.

  • H1 (Score:2, Funny)

    by JohnHegarty (453016)
    <H1>Your Hacked</H1>

    but i am sure there is more to it than that...
  • MS: switch to XP. (Score:4, Insightful)

    by Sarin (112173) on Thursday June 13, 2002 @05:15AM (#3692455) Homepage Journal
    "Microsoft Discloses Software Flaw"
    and
    "The server software included within Microsoft's newer Windows XP operating system was not affected by the security flaw."

    Sure it's these kinds of subtle remarks from interviewed microsoft officials that make companies -with little knowledge- want to switch to the more "secure" XP server package in a last effort to stay one step ahead of the evil "hackers". I bet there are a hell of a lot of disclosed software flaws under XP as well, perhaps even some backdoors -against terrorism ofcourse- within the upcoming servicepack who knows, but usually people don't understand that.
  • 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 ;)

  • by Erik Hensema (12898) on Thursday June 13, 2002 @05:40AM (#3692512) Homepage

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

  • 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.
  • Another Mozilla bug that will bring Windows XP to its knees is the "snow effect" bug ( bugzilla.mozilla.org/show_bug.cgi?id=64516 ) that hogs nearly 100% of the CPU time. XP's concept of multitasking is such that while CTRL-ALT-DEL will theoretically respond so you can kill the process, in practice you might as well hit the reset button (at least I've never had enough patience to wait). Please go and vote for this bug.
  • by Mongoose (8480) on Thursday June 13, 2002 @08:19AM (#3693072) Homepage
    The mozilla bug was known for some time by everyone on irc.mozilla.org #mozilla that tried my little url test link several weeks back. I gave warning before posting it but you know people. =)

    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.cg i?id=149014
  • What's the difference between a bug that allows remote access, and a bug that allows remote denial of service? None, really. In either case, you can't use your equipment properly, and there's a chance for data loss/corruption. And haven't "many eyes" been looking at the code for a hell of a lot longer than "three days?" I wouldn't exactly be calling this a victory for OSS.
    • [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.

  • by scrytch (9198) <chuck@myrealbox.com> on Thursday June 13, 2002 @11:20AM (#3694499)
    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.

Entropy isn't what it used to be.

Working...