Forgot your password?
typodupeerror
Mozilla The Internet IT

Unpatched Firefox 1.5 Exploit Made Public 309

Posted by CmdrTaco
from the caught-with-you-pants-down dept.
ThatGuyGreg writes "C|Net is reporting that an unpatched exploit in Firefox 1.5 has been made public, making it very easy for ne'er-do-well-sites to cause your browser to crash on startup with a single visit. Until a patch is released, it is recommended that you disable your history.dat file."
This discussion has been archived. No new comments can be posted.

Unpatched Firefox 1.5 Exploit Made Public

Comments Filter:
  • FC4, 1.5 (Score:4, Insightful)

    by (1+-sqrt(5))*(2**-1) (868173) <1.61803phi@gmail.com> on Thursday December 08, 2005 @06:27PM (#14214450) Homepage
    I can report that the exploit doesn't work on FC4, with the latest 1.5 built from source.
    • Re:FC4, 1.5 (Score:5, Informative)

      by Anonymous Coward on Thursday December 08, 2005 @06:40PM (#14214565)
      The Mozilla people are also reporting that the exploit doesn't seem to work on any version of 1.5:

      Mozilla Foundation, which released Firefox, said it was not able to confirm the browser would crash or be at risk of a DOS attack, after visiting certain Web sites.

      "We have gotten no independent verification that it crashes (Firefox), but there have been a lot of attempts to try," Schroepfer said.

      Apparently they're having a hard time duplicating this particular bug. Has anyone here on /. seen it actually happen?
    • by tyler_larson (558763) on Thursday December 08, 2005 @07:08PM (#14214766) Homepage

      False alarm. No security-related concerns, just overenthusiastic reporting.

      If you run the script below, it will create a page with a title that's quite huge. Close your browser and open it again. The browser will spin for about 2 minutes what it tries to make sense the contents of your history file. Once it's finished, you'll be back up and running, with no degradation in performance or visible side-effects. You'll be able to even view your browsing history (including the offending page). In fact, I'm posting this response after following the process described above (on WinXP), and I have a history entry entitled "AAAAAAAAAAAAAAAAA..."

      A bit of an annoyance, but hardly a security issue.

      Here's the official exploit code:

      function ex() {
      var buffer = "";
      for (var i = 0; i < 5000; i++) {
      buffer += "A";
      }
      var buffer2 = buffer;
      for (i = 0; i < 500; i++) {
      buffer2 += buffer;
      }
      document.title = buffer2;
      }
      • You'll be able to even view your browsing history (including the offending page).

        Addendum:
        As you might expect, if you delete the offending entry from your history, everything returns back to normal: you don't actually have to do anything drastic like delete your history.dat file, or even clear your browsing history.

      • Well, that code may make your browser sit and spin for about 120 seconds before working, but one could conceivably make that time a whole lot longer with some exponential magic:

        function ex() {
        var buffer = "A";
        for (var i = 0; i 5000; i++) {
        buffer += buffer;
        }
        document.title = buffer;
        }

        And that would truly be a pain in the ass.

        But it occurs to me: would it be practical to add an option to Firefox which limits the physical size of your history file, which the user c
      • I get identical results running the "exploit" on OS X 10.4.2. Taking a sample of Firefox when it relaunches confirms that it's spending a lot of time in nsGlobalHistory::OpenDB(), and ultimately in memory allocations and frees as it reads the huge entry. It does eventually finish and then behaves normally. This isn't a security hole, and it's only a DOS in the sense that Javascript of "while (1) {}" is.
    • Yeah....the article says it affects XP SP 2
    • Non-Story (Score:5, Informative)

      by Midnight Thunder (17205) on Thursday December 08, 2005 @07:14PM (#14214807) Homepage Journal
      C|Net has added the following correction at the end of the story:

      "Correction: This story incorrectly stated the affiliation of Mike Schroepfer, Mozilla's results in verifying the Firefox 1.5 flaw, and the nature of the problem. Schroepfer is vice president of engineering with Mozilla Corp., and Mozilla has not been able to verify its browser can crash and lead to a denial-of-service condition. The problem itself was not a security vulnerability but actually a flaw in the browser."

      So Firefox crashes, but no security vunerabilty.
  • Good Thing (Score:5, Funny)

    by Anonymous Coward on Thursday December 08, 2005 @06:29PM (#14214460)
    I'm still using Internet Explorer!
  • The fix (Score:5, Informative)

    by rnelsonee (98732) on Thursday December 08, 2005 @06:29PM (#14214469)
    If it's already happened to you, just delete your history.dat file in your profile folder, and FireFox will create a new (empty) one on startup.
    • Re:The fix (Score:3, Funny)

      by d34thm0nk3y (653414)
      Heh, thats funny. There are 3 highly modded posts saying to just delete the history file. Hmmm.... why would Slashdotters be so familiar with a procedure such as that?

  • "Unpatched firefox 1.5 exploit made public recently by an unknown source who refused to name himself or other..." *crash*
  • by dotslashdot (694478) on Thursday December 08, 2005 @06:30PM (#14214474)
    Dat file will be history, man.
  • Only crashes? (Score:5, Informative)

    by ruiner13 (527499) on Thursday December 08, 2005 @06:30PM (#14214481) Homepage
    If this only crashes Firefox, how is it an "exploit"? I tend to use "exploit" as something that an attacker can use to their advantage to do something malicious. This is just an annoyance to have to move my poor cursor back to the icon and issue an oh-so-painful double-click.
    • Re:Only crashes? (Score:4, Insightful)

      by courtarro (786894) on Thursday December 08, 2005 @06:35PM (#14214523) Homepage
      There are plenty of browser denial-of-service bugs, but few of them can actually render your browser useless upon every execution. This one has a lasting effect that's more significant that the old "do while(true) alert;"-style DoS attacks. A single double-click won't fix this one; you have to delete your old history.dat file.
      • Ok, so a right click, click, then double-click :) Still easier than having to reformat and reinstall windows because my computer has become a zombie. If this were IE, being tied into the OS as it is, a crash of your browser is far more likely to have other effects on other running processes.
    • Re:Only crashes? (Score:3, Insightful)

      by Anonymous Coward
      If it causes a crash, it's entirely likely that some malicious code could be injected into memory when that happens! If so, you're potentially up shit creek.
      • Re:Only crashes? (Score:2, Interesting)

        by Da_Weasel (458921)
        lets say that some malicious code gets "injected" into memory when Firefox crashes. What are the dangers? If Firefox crashes then its not going to attempt to use that memory for anything...because...ummm....it's not running! If it's not running then it can't be tricked into doing something with this malicious chunk of memory. The only other thing that is going to be looking at that memory space is the OS, and that would likely only be concerned with reclaiming those blocks of memory for use by other pro
        • Most usual reason for a crash is when a program tries to access a random(ish) memory location - it has no right to, so it segfaults. But if it's doing that it's often only one more step to making it access a particular memory location - in particular, to jump into the data you've just given it.
    • by MushMouth (5650) on Thursday December 08, 2005 @06:37PM (#14214536) Homepage
      When an app crashes (firefox does quite often for me) it means that it is doing something that the programmer didn't expect. That could be all sorts of things, from taking all the cpu, to writing to memory that it shouldn't be. Most overflow exploits started as mere crashes.
      • Most overflow exploits started as mere crashes.

        While that is true, this could also be a simple null pointer dereference, caused by incomplete error handling in the code somewhere. Those sorts of failures are typically not exploitable.

        Just because A implies B, does not necessarily mean that B implies A. All overflows are crashable bugs, but not all crashable bugs are overflowable.

        It's easy enough to find out -- load the core file into gdb and look at the instruction that crashed. If it's a null refere

      • You seem to be confusing "could be" with "is". Yes this "could be" all sorts of things but it's not a security hole. It doesn't even crash the browser, it just slows it down for a while.

      • I guess you guys failed to read the words "CAN OFTEN" in my comment title. Not that it is known that this particular one does, but anytime you have an app crash from an outside influence it is what else that is possible to do with it isn't always known and can lead to much more than just a DOS. While you can delude yourself into thinking that this is nothing. Remember that the IE "critical" bug from last week was just a DOS for six months.

    • Re:Only crashes? (Score:3, Insightful)

      by Jugalator (259273)
      Crashes may be signs of buffer overruns and access violations, which is a bad thing not only from the app's and user's perspective, but also from a security perspective, e.g. if the memory space was prepared earlier with malicious code.
    • Re:Only crashes? (Score:3, Insightful)

      by Thundersnatch (671481)
      The vulnerability is incorrect handling of input. In this case, the only *exploit* published so far is a DoS. But obviously there's something very wrong with the input validation in the code, and remote execution may be possible with a more clever exploit.

      Witness the recent IE vulnerability, which MS didn't patch quickly because it was "only a DoS vulnerability". Of course, it turned out it was possible to execute code with the vulnerability, it just took a while for a better (worse?) exploit to be crafted.
      • There is nothing wrong with the input code. It works just like intended. The only problem is, it's possible to create a long title and slow down the browser startup (that is, until you clear the history file). Not to mention, who the hell uses the history feature, anyway? It's the first thing I turn off.
  • Incremental updates (Score:3, Informative)

    by moonbender (547943) <<moc.liamg> <ta> <rednebnoom>> on Thursday December 08, 2005 @06:31PM (#14214484)
    Sounds like a great opportunity to show off the snazzy automatic incremental update feature Firefox 1.5 has. Pushing a fix quickly to users who've got it enabled would be great.
  • by tjwhaynes (114792) on Thursday December 08, 2005 @06:31PM (#14214485)
    For anyone out there who wants a safer experience out on the web, you owe it to yourself to install the NoScript extension and only allow whitelisted sites to run Javascript. The exploit published this morning (more a DoS and only seems to affect some but not all installations of firefox 1.5 according to SANS [sans.org]) uses a Javascript loop to build up an enormous topic that ends up being written into your history.dat file causing buffer overflow issues. Without Javascript, this sort of exploit is much tougher.

    Cheers,
    Toby Haynes

    • by Psykus (827143)
      The NoScript extension [mozilla.org] itself.
    • Stop the stupidity (Score:2, Insightful)

      by NineNine (235196)
      Another tip for you: if you remove the gas pedal from your car, you won't have any crashes! Really!

      DOWNLOADING MORE SOFTWARE to intentionally disable part of a program that is supposed to work is 150% unacceptable.

      Jesus, how bad does software have to get before people finally start to not use it? Luckily, I didn't pay anything for my Firefox installations, so I can't really bitch. But I CAN look at other, less buggy alternatives (like IE) that also offer useful features that Firefox doesn't, like Activ
      • DOWNLOADING MORE SOFTWARE to intentionally disable part of a program that is supposed to work is 150% unacceptable.

        I've always wondered why more browsers don't have JS enable/disable widgets by default. Konqueror has had this for eons and I love it dearly. My whitelist is small and is a trusted set of hosts. (now, the only problem with Konuqueror's JS implementation is that it fails on more sites than I'd like... Though 3.5 is supposed to be much better with JS.

      • I CAN look at other, less buggy alternatives (like IE) that also offer useful features that Firefox doesn't, like Active X.

        Is that humor, or flamebait? It can be so difficult to tell...

        how bad does software have to get before people finally start to not use it?

        Yea, why DO people use JavaScript anyway ? But seriously, people are still using Windows, so... I guess the answer is "really, really bad".
        ;-)

        Humor, people, humor!

    • The poster is right. Back when I used linux, I liked this feature.

      Today I browse with Safari on OSX, and I have javascript turned off by default. This is seldom problematic, since it's easy to turn javascript on for a moment once a week when it provides more than annoying eye candy.

    • by Kelson (129150) *
      Sure, the proof of concept uses JavaScript. But the problem itself has nothing to do with scripting. One could easily generate a 2.5MB HTML file with a really long title. 2 million "A"s in a row will probably compress pretty well, so if you serve it with on-the-fly compression, it doesn't have to take much extra time or bandwidth to retrieve.

      Bingo: exploited with no scripting involved at all.
  • DOS (Score:5, Insightful)

    by kihjin (866070) on Thursday December 08, 2005 @06:31PM (#14214490)
    The 'exploit' seems only capable of a Denial of Service. There's no proof to indicate that malicious code could be executed.

    Plus, read this (from the article):

    "We have gotten no independent verification that it crashes (Firefox), but there have been a lot of attempts to try," Schroepfer said.

    So, this is all very hypothetical then?

  • ummmm (Score:3, Funny)

    by Prince Vegeta SSJ4 (718736) on Thursday December 08, 2005 @06:31PM (#14214494)
    thats what thet get for making an extension that runs explorer within firefox https://addons.mozilla.org/extensions/moreinfo.php ?application=firefox&id=1419 [mozilla.org] *ducks*
  • Not an "exploit" (Score:4, Insightful)

    by joetainment (891917) on Thursday December 08, 2005 @06:32PM (#14214497)
    This isn't even related to security. Its just a bug.... lots of apps crash when something happens. Doesn't mean its ok, but it doesn't represent a security issue does it? (Unless I'm missing something...)
  • by courtarro (786894) on Thursday December 08, 2005 @06:32PM (#14214499) Homepage
    Those of us with sturdy tin hats already have our histories disabled. Take that, evil!
  • Really (Score:2, Insightful)

    Is it just me or is this a pretty worthless report? I can't really see this as being an exploit anyone would care about unless you happen be work for a certain company in Redmond.
  • by Schrade (902157) on Thursday December 08, 2005 @06:33PM (#14214508) Journal

    Quote from the bottom of the article:

    Correction: This story incorrectly stated the affiliation of Mike Schroepfer, Mozilla's results in verifying the Firefox 1.5 flaw, and the nature of the problem. Schroepfer is vice president of engineering with Mozilla Corp., and Mozilla has not been able to verify its browser can crash and lead to a denial-of-service condition. The problem itself was a not security vulnerability but actually a flaw in the browser.

    Read the article before you consider posting it with a sensational title!

  • by Dreadlord (671979) on Thursday December 08, 2005 @06:33PM (#14214513) Journal
    Before someone starts saying Firefox is vulnerable to exploits just as IE, this exploits crashes the browser and only that, now compare this to IE's execution of arbitrary code [slashdot.org].

    No software is perfect, but still, Firefox is clearly ahead.
    • And a while back firefox had a bug (in Windows) that allowed access to a shell. Knowing the number of people that run with admin access, this is just as bad. I'm not saying FF is as bad as IE, just that bugs can be brutal. (and undescriminating)
      • The origin of the bug is Windows and its shell: protocol, Mozilla simply handled those links back to the OS ad it does with protocols it doesn't know how to handle, other programs like MS Word were vulnerable to the very same exploit.

        It was fixed 24 hours after full disclosure, and only Win32 versions of Mozilla were vulnerable, doesn't this ring a bell?

        Anyway, read this link [newsforge.com] for more info.
    • Wow, a pre-emptive counter-flame.
  • by brandonp (126) * <<moc.liamg> <ta> <nesretep.nodnarb>> on Thursday December 08, 2005 @06:35PM (#14214518) Homepage
    This will be a good test for the new Update System that was implemented in Firefox 1.5. Too bad it will need to be utilized so soon.

    With the speed that the Firefox developers release their fixes and the ease of getting those fixes with the new system, I hope this will develop as proof of how well Firefox can handle these situations.

    --
    Brandon Petersen
    http://www.brandonpetersen.com/ [brandonpetersen.com]
  • by ninja_assault_kitten (883141) on Thursday December 08, 2005 @06:37PM (#14214534)
    The guy who reported it called it a 'buffer overflow' and clearly had no understanding of what it actually meant.

    which
    most users won't figure out.

    this proof of concept will only prevent someone from reopening
    their browser after being exploited. DoS if you will. however, code
    execution is possible with some modifcations.

    Tested with Firefox 1.5 on Windows XP SP2.

    ZIPLOCK

    -->

    heh
    function ex() {
                var buffer = "";
                  for (var i = 0; i ZIPLOCK says CLICK ME

    • Um. A buffer overflow is whenever the code attempts to store a large data element in a small buffer without adequate protection. This is what Firefox does when you attempt to start up and it hits the too-large history entry.

      I haven't looked at Mozilla's parser code, so it isn't clear exactly effect the buffer overflow will have. But it is a buffer overflow by definition.
  • Heh (Score:5, Funny)

    by aftk2 (556992) on Thursday December 08, 2005 @06:37PM (#14214538) Homepage Journal
    cause your browser to crash on startup with a single visit.
    I've seen this exploit in the wild: it's called the MySpace Profile Page [myspace.com].
    • Speaking of MySpace, is there a way (short of filling Firefox with FlashBlock, AdBlock, NoScript, KillTheWabbit, or whatever other anti-active-content extensions they have) to view MySpace profiles/information without loading any of the simultaneous nonsense my friends seem to want loading by default? E.g., if I log in, is there an option to disable this? Or is there a relatively complete RSS feed for profiles?
    • So are you trying to say it's a feature?
  • by Godeke (32895) * on Thursday December 08, 2005 @06:38PM (#14214542)
    Correction: This story incorrectly stated the affiliation of Mike Schroepfer, Mozilla's results in verifying the Firefox 1.5 flaw, and the nature of the problem. Schroepfer is vice president of engineering with Mozilla Corp., and Mozilla has not been able to verify its browser can crash and lead to a denial-of-service condition. The problem itself was a not security vulnerability but actually a flaw in the browser.


    Wow, that is accurate reporting, which was then amplified in the summary to the point of absurdity.
    • Well quite.

      C|Net, by their own admission, got almost every pertinent detail of the story wrong. The only way they could have have been further off target would be if they assigned the flaw to Internet Explorer. Personally, I'm not going to hold my breath waiting for that mistake to see print.

      As a side note: I'm not normally one to slag off Slashdot's editors, but might I ask for a little more investigation before parrotting the lastest MS anti-Firefox propaganda? This is the third story this quarter por

  • by sheepoo (814409)
    I ran the proof of concept on my installation of 1.0.7 (WinXP SP2) and it crashed the next time I opened FF. Task Manager showed that FF was eating up the memory like crazy. I deleted the history.dat file (which was 10 MB in size!!!!!!!) and sanity returned instantly :)
  • Do older versions of Firefox and Mozilla have this problem?
  • by Anonymous Coward
    In other news: Water is wet. Seriously, whoever wrote the history code needs to be shot. Once your history gets to any significant size, all operations on it start getting annoyingly slow. For me, it takes 15 seconds for firefox to open the Go menu for the first time in a session, and once you've done that, even more annoyingly there's a delay of a few seconds on every new page you visit for the rest of that session. The history sidebar is so excruciatingly slow it's practically unusable.
    • by WWWWolf (2428) <wwwwolf@iki.fi> on Thursday December 08, 2005 @07:54PM (#14215085) Homepage

      Once you have the idea on how sucky Mozilla's history stuff is in practice, take a look at how the stuff is actually stored in history.dat. People have been rendered insane by just a single look at that stuff. Want to make sense of this format for some obscure reason? Read this [livejournal.com] and weep [jwz.org]. This stuff is just about the most insane thing I've ever seen.

      I sure hope Mozilla folks get the unified storage plans together for Firefox 2.0, and use something like sqlite to store most of the user data. MorkDB format used by Mozilla is... just not elegant.

  • so... (Score:5, Informative)

    by SharpFang (651121) on Thursday December 08, 2005 @06:48PM (#14214623) Homepage Journal
    Preferences > privacy > history > [0] days; ok.
    Patched. I use the history feature about twice a year, won't miss it till the right fix is found.
    Not quite like disabling all the javascript in MSIE, is it?
  • The browser crashes when I go to a site? OMG! If its not arbitrary code execution, don't bother me. IE has had a similar exploit since it came out. Basically, it crashes randomly when visiting a website.
    • "IE has had a similar exploit since it came out."

      You're confusing the terms "exploit" and "vulnerability". All products have vulnerabilities. The ones that the vendor are aware of are called "known vulnerabilities". When code is written that takes advantage of a vulnerability, it's referred to as an exploit. When an exploit is written for a vulnerability that is not known by a vendor, that's called a Zero Day exploit. Some will argue that a Zero Day is when an exploit is written for a vulnerability that

  • Some exploit. (Score:3, Insightful)

    by bradbeattie (908320) <bradbeattie@alum ... a ['erl' in gap]> on Thursday December 08, 2005 @06:58PM (#14214695) Homepage Journal
    I recognize that it can cause inconvenience, but come on. Exploits in IE typically result in executing arbitrary code on the user's computer. I guess this is just another argument as to why system diversity is important. If no browser had more than 20% of the market it'd be difficult to target a large portion of internet users.
    • If no browser had more than 20% of the market it'd be difficult to target a large portion of internet users.
      Ummm.... 20% is still a really big slice of the pie.

      And yea, I've never heard a DoS refered to as an exploit.
  • Must be joking (Score:3, Insightful)

    by Charles Dodgeson (248492) <jeffrey@goldmark.org> on Thursday December 08, 2005 @07:18PM (#14214843) Homepage Journal
    The effect makes restarting Firefox very very slow (several minutes). I've just tested on OS X and on SuSE 9.3. Once that is done you can clear history through Prefences. If you don't want to wait, you can remove or manually edit history.dat.

    The claim of a buffer overflow is nonsense. I suspect that that claim is a joke. The only thing that makes this mild borking work is a very long document title. In setting that up, the author uses a variable called "buffer" and "buffer2". Just because a JS variable gets named "buffer2" and gets set to something very long doesn't make this a buffer overflow. I like to think that the guy must be joking, instead of actually being that stupid.

    But in the end, there is a bug to be fixed in Firefox

    • Is this the same thing as this (this link is safe to click but read carefully before clicking the links within)? It is a buffer overflow on IE but on Firefox it just completely freezes up the browser/potentially opens tons of windows.
  • "No, the history hasn't been cleared because I've been looking at porn! It's the exploit, I tells ya! The exploit!"
  • I'm running Firefox 1.0.7 on Kubuntu (Breezy Badger) and it doesn't crash here. It definitely hung for a good long while on the next startup while it tried to parse the history file, but it did eventually start up normally.
  • Obviously, any website that lets users specify javascript in, e.g, a forum or blog post is going to be a cross-site-scripting nightmare. However, and while I'm not entirely sure of this, it would seem that an overly long HTML title would cause this bug itself, correct? A lot of the bulletin board software I've seen uses the thread title as the page title. Assuming that somewhere out there there is some similar blog/forum software which doesn't impose a size limit on the title ("Duh, people wouldn't be ab

UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20 1985 GMT (measuring since the time(2) epoch). -- Andy Tannenbaum

Working...