Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

Privacy Leak in Mozilla and Mozilla-Based Browsers 358

Mike S. writes "Mozillazine has pointed users to this story at ZDNet UK which breaks the news about a privacy bug discovered in in all Mozilla builds up to and including 1.2a as well as browsers based on Mozilla such as Netscape 6/7, Chimera and Galeon. The bug allows a web site to track where you're going when leaving the site whether you use a link, a bookmark or type a URL into the address field. This page has a demonstration of the bug and instructions on patching it via a user.js file."
This discussion has been archived. No new comments can be posted.

Privacy Leak in Mozilla and Mozilla-Based Browsers

Comments Filter:
  • by Corvaith ( 538529 ) on Sunday September 15, 2002 @08:30PM (#4262946) Homepage
    ...is that the bug has apparently been a known one for months, and still hasn't been repaired.

    I love Mozilla. I use Mozilla. This just troubles me greatly. Even now that it's known, I haven't heard anything about a fix. Hopefully it'll be arriving shortly, because I like my privacy.
    • by jmcnamera ( 519408 ) on Sunday September 15, 2002 @08:39PM (#4262997) Homepage
      If this bug has really been known for months, are we hypocritical to bash others (always MS) for late fixes?

      Bugs should be publicized immediately so fixes will happen sooner. It's good to first inform those who are responsible for the code so they can have a heads up, but months (if true here) is too long to wait.
      • Quite possibly hypocritical... though, in general, I don't think this is quite the same severity as many of the MS ones seem to be. I'm not even bothering to apply the patch, at the moment, and I'm not so much upset as baffled. Usually, Mozilla's bugs don't stay around this long.

        Which is not to say that they don't frequently disappear and reappear regularly as the flaws are hammered out, but for something to be completely untouched after this long is certainly not usual.
        • by Chuck Chunder ( 21021 ) on Sunday September 15, 2002 @08:54PM (#4263075) Journal
          Is that as breeches go it is a fairly minor one with a trivial work around, yet it remained confidential in bugzilla.
          If it isn't a big enough security hole to warrant instant attention then it should not be hidden in bugzilla, so anyone can have a whack at fixing it.
          • The workaround is to disable the onunload handler. This is the kind of workaround that breaks legitimate applications.
            • by Idaho ( 12907 ) on Monday September 16, 2002 @05:57AM (#4264446)
              The workaround is to disable the onunload handler. This is the kind of workaround that breaks legitimate applications.

              Are you going to tell me there actually are legitimate uses for unonload!?

              I use the internet since 1996 and have yet to come across the first site that uses this 'feature' *cough* in a usefull, non-irritating manner (i.e. something else then opening a bazillion new popups as soon as you close the previous one)

              I can not imagine why onunload exists in the first place - 2nd, I can not imagine why people would ever leave it on if they can turn it off.

              But maybe that's just because my imagination is so limited :)
          • by jesser ( 77961 ) on Sunday September 15, 2002 @11:31PM (#4263598) Homepage Journal
            If it isn't a big enough security hole to warrant instant attention then it should not be hidden in bugzilla, so anyone can have a whack at fixing it.

            The bug was public for two months before it was marked as security-sensitive. There isn't an army of coders who spend all of their time fixing known minor privacy bugs. The bug had the "privacy" keyword for almost two months before it was marked as security-sensitive, so it would not have been invisible to such an army.

            I'm not saying it was a good idea to make it security-sensitive after it was open for a while. It wasn't a good idea in this case, because someone who had seen the bug while it was public decided to make it public again. I'm just saying that leaving it open probably would not have led someone to fix it immediately.
      • It seems to me that privacy bugs often get short shrift in Bugzilla [mozilla.org]. I believe we're still waiting to get inline loads blocked within mail messages (i.e. for web bugs).

    • by Anonymous Coward on Sunday September 15, 2002 @08:52PM (#4263058)
      > This just troubles me greatly.

      Fine, this is not how you'd expect it to work.

      But, GIVE ME A BREAK. Privacy issues on the Web are legend. Cookies, refer, hidden fields, the entire body of software we know as "IE", the list goes on and on and on.

      So, by some new "stupid browser trick" you can now see where people are going -- not just where they've come from (as has always, forever, been the case).

      Oh my.

      If you are worried about "privacy" then you have been using an appropriate "junk busting" proxy from day one.

      If you are not using such a proxy, then you are not now, and never have been, seriously worried about privacy. And, this "horror of horrors" is no more an issue to anyone than the Referrer field.

      This sounds more like Microsoft Marketing pouring though a Bug Base and using the media to turn a mole hill into a mountain.

      Should it be fixed? Yea. So should Referrer be removed from existence. So should alot of much more pressing privacy issues be outright abolished.

      So go back to sleep. If you weren't worried about this yesterday, then there is no reason for you to be worried about it today.

      • I think you misunderstand a few things about the interweb...

        Firstly, the referer [sic] field only contains the URL of a *referring* page, not just any page you happened to be on before. Why? Because sending non-referring page URLs is an invasion of privacy. Furthermore, IE and Mozilla both stop you actually retrieving this data from Javascript, even though you can pass it to certain Javascript functions, showing that again this privacy is respected.

        May I suggest you find out how your interweb browser works before posting in the future? Oh, and read the RFC: it's Referer field, not Referrer field.
    • by cpeterso ( 19082 ) on Sunday September 15, 2002 @09:35PM (#4263217) Homepage

      Mozilla is open source. Why haven't YOU fixed this bug yet?
    • If you care to follow that link...
    • by Anonymous Coward
      > ...is that the bug has apparently been a known one for months, and still hasn't been repaired.

      Oh, give me a break. This flaw is so minor that I am not even going to bother to install the fix (I will wait for the next Mozilla release).

      This bug allows a website to see the URL of the next site you are going to. It is little different from what all browsers have always done, when they provide the URL of the site you came from. If either one worries you, then just click on "home" before typing in a URL.

      So how "disturbed" should you be? Let's put this case into perspective. Let's look at some of the IE security holes that Microsoft is currently sitting on, in some cases for over six months...

      There are currently _19_ unpatched security holes in IE [pivx.com].

      Here are some samples:

      > Who framed Internet Explorer
      > Description: Cross-protocol scripting, arbitrary command execution, local file reading, cookie theft, website forging, sniffing https, etc.


      > MS JVM native method vulnerabilities
      > Description: A collection of at least 10 different vulnerabilities in the MS JVM, escaping the sandbox, local file reading, silent delivery and execution of arbitrary programs, etc.


      > WMP Stench
      > Description: Silent delivery and installation of an executable on a target computer


      > Java XMLDSO base tag
      > Description: Arbitrary local file reading.


      > delegated SSL authority
      > Description: HTTPS spoofing, man-in-the-middle attacks, etc.


      > document.domain parent DNS resolver
      > Description: Improper duality check leading to firewall breach


      > CTRL-key file upload focus
      > Description: Local file reading, downloading and executing arbitrary code.


      > IE https certificate attack
      > Description: Undetected SSL man-in-the-middle attacks, decrypting SSL-encrypted traffic in realtime.
      > Published: December 22 2001 ( Stefan Esser )
      > Published: June 6 2000 ( ACROS )
      > Status: Initially fixed in IE4 and early IE5s by MS00-039, re-introduced by a later patch.


      Arbitrary command execution? Local file reading? Escaping the sandbox? HTTPS spoofing? Firewall breach? Decrypting SSL-encrypted traffic? Yikes!!!

      Of the nineteen open security holes in IE, nine of them allow binary executable code to be run on your computer.

      Compared to that, this Mozilla bug is so minor that it barely deserves mentioning.
  • Dear Slashdot morons (Score:5, Interesting)

    by rebrane ( 17961 ) on Sunday September 15, 2002 @08:31PM (#4262956)
    Do not link to BugZilla from the front page. Not only is it extremely impolite to overload their system with a bunch of hits from people who have no actual interest in the page, but they have disabled links with a slashdot referrer anyway. I'm sure some clued person will go to the bug report and relay any pertinent information in the comments anyway.
    • by Neon Spiral Injector ( 21234 ) on Sunday September 15, 2002 @10:28PM (#4263425)
      Have they also disabled people leaving Bugzilla to go to Slashdot? Okay, I know that was bad.
    • No. If this bug was fixed months ago when it was first detected, then there would have been no problem. However, the slashdot ultimatum was issued and appropriately followed through.

      We will not tolerate ourselves to look stupid while accusing other companies of leaving security holes for months, and then doing it ourselves. Do it again, and we will slashdot you again. And yes, we will defeat your referrer. Thank you, have a nice day. :)

      • Chill!

        It's not a "we get to rape your local filesystem" bug. It's a "web surfing history" bug. It's not that scary.

        I prefer to look at the bright side. It's fixable with a userland .js file with no recompiling. That's sort of neat.

  • by RPoet ( 20693 ) on Sunday September 15, 2002 @08:31PM (#4262961) Journal
    People will tell you to disable Javascript alltogether for protection, but it's better to just disable the onunload event. Just put the following line into your user.js file:

    user_pref("capability.policy.default.Window.onun lo ad", "noAccess");

    You won't miss those ununload events anyway :)
  • No Big Deal (Score:3, Interesting)

    by md17 ( 68506 ) <james@@@jamesward...org> on Sunday September 15, 2002 @08:32PM (#4262966) Homepage
    I very highly doubt that any site that I visit will be exploiting this bug. Who would waste the time to do this when only about 1% of their visitors will be susceptible to the user tracking. Yeah, I am concered about privacy, but is this really news? Thanks /. for keeping me informed.
  • I do everything in Mozilla in tabs. I open new sites in tabs, I'll even load other pages in tabs (middle click is your friend). As a result, they can't spy on me, because I don't go anywhere in that tab once I get there. If (and that might be a pretty big if) that is how you do your browsing, this bug isn't a big deal.
  • HTTP_REFERER (Score:5, Interesting)

    by nick_davison ( 217681 ) on Sunday September 15, 2002 @08:38PM (#4262989)
    The bug allows a web site to track where you're going when leaving the site whether you use a link, a bookmark or type a URL into the address field.

    It always bemuses me that people seem to think these things are new. Tracking exits is relatively simple and as for how people access your site, just check HTTP_REFERER. Typed URLs and bookmarks show no referer, links show you who sent them to your site. Granted, it's not 100% infalible, but it works on any browser. I'd rather trade 80% accuracy 100% of the time than 100% accuracy on 5-10% of hits.

    From time to time, it still amuses me to be watching the logs while I'm chatting to a visitor via Messenger and tell them what system they're running, what their screen res is, color depth, what enabled/disable features they have and the path they've taken through the site. If you're really that bothered, JavaScript even lets you track their mouse's movement around and how they scroll up/down the page and then play it back on your own PC, telling you things like how fast they read and what they paid attention to.

    • It's more or less the inverse, this bug enables the referer to know where they refered you to.
      Of course, if you really wanted to do that then in most cases you'd just set up a bounce script on your server, much like freshmeat does, so that it would work on anyone.
      • It's more or less the inverse, this bug enables the referer to know where they refered you to.

        Grandparent was talking about the CGI scripts used to track users who click an outward link on a web site. (Some Slashdot users abuse those scripts to create a link that appears to go to Yahoo! but really goes to Goatse.cx [yahoo.com].) However, this bug in Mozilla gives a site's scripts access to a clicked bookmark or to a URL entered in the location bar.

    • HTTP_REFERER tells you where you came FROM to get to the page in question (and only if the user clicked a link). The bug tells you where you're going TO.

      This is significantly more of an invasion of privacy than you make it out to be. If a website owner knows that I clicked a link on cnn.com to get to your page, that's no big deal. With this bug, however, a web page can track if I, out of my own whim, decide to go to porn.com after visiting your site. This is decidedly unexpected behavior, since if I'm entering in addresses into the goto bar myself, I don't expect anybody to be tracking my behavior.

    • Re:HTTP_REFERER (Score:4, Informative)

      by singularity ( 2031 ) <nowalmartNO@SPAMgmail.com> on Sunday September 15, 2002 @09:18PM (#4263157) Homepage Journal
      As with a lot of browser-based things that show up on Slashdot, I feel the need to chime in with a different perspective, from a browser that does a lot of these things correctly.

      iCab, on the Mac, has a setting (and has had it almost since its very first versions) to only allow the Referrer: to be sent only when in the same domain (or even never sent). So Sony.com can trace how I look through their site, but cannot see that I came to Sony's site from a link on slashdot.org

      I could even set it to never send it, as well.
    • The problem with this bug is that they can tell where you're going next, regardless of whether you click a link, use a bookmark, or type the URL in yourself.
  • At least for me. I tried the windows enigmail on 1.0a, 1.1a, and now 1.2a, and none of them work. GnuPG is installed in c:/gnupg where it belongs... I thought this shit was supposed to be seamless.
  • .. how many people are saying "no big deal". If the article stated:

    "The bug in Internet Explorerallows a web site to track where you're going when leaving the site whether you use a link, a bookmark or type a URL into the address field"

    you would hear a dplethora of privacy zealots bitching and moaning how this is typical M$ practice and blah blah fucking blah.

    Because of a /. article and because I'm OS/Software egnostic, I tried Mozilla 1.0 which was a horrible product. I could repeatedly lock up the browser simply by going into the preferences. Maybe it's been fixed 1.0.1, but I'm not willing to waste my time, especially since IE runs just fine.

    I have excellent Karma, so if you can't handle the truth, mod me down, I don't give a shit, I'm just sick of the "hippicratical oath" /. editors have taken.
    • It is actually kind of a big deal, but I'm not even going to bother patching it. I actually find OnUnload events to be handy as long as "open unrequested windows" is disabled.

      So: people on Slashdot like Mozilla. This bug isn't a big enough deal to really affect anyone, so they don't complain.People on Slashdot hate Microsoft. The bug still isn't a big enough deal to do something about if you're affected, but you can point and laugh at Microsoft about it nonetheless.

  • The YOU online updater in Yast has been set up to automatically download and install the patch for a coupla months now. Of course, it only applies to the default 0.98 Mozilla version included with the distro, but for those who haven't upgraded, it's there.
  • Muwahahaha (Score:4, Informative)

    by evilviper ( 135110 ) on Sunday September 15, 2002 @09:10PM (#4263125) Journal
    Well, this just proves my point. Javascript should be disabled. (check my older posts, it's there somewhere).

    Anyhow, I think everyone should look into Privoxy [privoxy.org]. In my setup, I have all on(un)load tags removed, and the refer forged to report the it as root of the current server.

    It's quite nice. You simply setup a regex to replace/remove any HTML, you can configure that feature on a site-by-site basis, and do so using a simple web-editor.

    So, check it out, and take back full control of your browser.
    • A very nice plan, unless a website is using the Referer field for authentication, and then you're blocked out. Ach-well, if taking control of my browser means being locked out of many of the sites I visit, then I guess I'm happy being exploited by those evil people who *gasp* know which site sent me to them.
  • by FyRE666 ( 263011 ) on Sunday September 15, 2002 @09:11PM (#4263131) Homepage
    The last few builds have introduced more bugs than ever. It seems to me that spangly new features are being introduced at the expense of the browser's stability and performance.

    For instance, the new keyboard stuff in 1.2a (ok, it's an Alpha I know), had screwed up Javascript's keydown events - the browser intercepts them first, then passes the event to the scripting engine so if a key is held down you get the anoying error "bell" as the buffer is filled. Keyboard events->javascript is/was also broken completely in the Mac/Linux port from 1.1. 1.2a is also slower than 1.1 at rendering dynamic content - especially content that involves keyboard input (like games) due to the problem above.

    Also when will they fix the damned image clipping bug in linux that's been there for 2 sodding years now?!! For those who haven't seen it, when clipping an element containing images that have transparency, everything except the images will be clipped, completely ruining the layout of dynamic scripts.

    I guess no-one wants to work on the boring stuff like making it work when there's sidebars, tabs and themes to be had...

    </rant>
    • The number of people who know enough about the view manager to fix that clipping bug is about... 2. Of these two, both are full-time students (one's a grad student who spent the summer actually trying to make progress on his thesis). So they just haven't had the time to get into this problem....
  • by Parsec ( 1702 )

    For this demonstration, the image loaded is really a script that sets a cookie with the request referer.

    I just said "no" to the cookie dialog and that appears to have broken the example.

    If you're going to raise a stink about your browser's security, why are you accepting any and all cookies?

    • Dude, the first line reads

      For this demonstration, you need to enable cookies. The bug itself does not require cookies to be enabled, however.

      I think that explains the situration pretty clearly.

  • I looked at my settings, and was amused to find that I had disabled javascript's ability to create/mess with cookies. I'm happy the Mozilla team partioned the javascript functionality like this, because (it appears anyway) that until a bug fix is available, you only have to disable this one aspect of javascript.
    • The bug has nothing to do with cookies, the cookie is just so that the demo site can tell you where you went after visiting there. The problem is with the window.onunload javascript function - so either that needs to be disables, or all of javascript (the instructions are on the demo page for how to only disable onunload). All that stopping javascript playing with cookies will do is stop the demo from being able to tell you where you went, the server operators can still find out if they wanted.
  • by coene ( 554338 ) on Sunday September 15, 2002 @10:12PM (#4263373)
    But why is it when its an IE bug, its a "Severe Security Exploit", and when its a Mozilla bug, its a "Privacy Leak"...

    George Carlin said it best, that we think in language. Changing the rhetoric that is used to describe the problem doesent change the problem. You can be Anti-Microsoft all you want, but that is worth NOTHING if the software that you choose to use exhibits the same problems, and you are not honest about them.

    Again, I'm not taking Microsoft's side -- there aren't sides to take. Open Source software needs to be just as accountable as commercial software if it's to be taken seriously.
    • There is a bit of a difference between allowing a server to track your next site from their own site and a hole in IE allowing a hacker to enter and exploit your system, or a hole in OE that allows viruses to propgate, using your machine like a 2-dollar whore. You're right on two points-- it is still privacy. But there is a distinct difference between someone watching you to see where you live and the act of breaking in to your home to steal your underwear. And yes, open source software needs to be just as accountable. And I'm sure they will be... they'll fix this problem. Whatever the semantics, it is still a problem and it will still be fixed.
    • But why is it when its an IE bug, its a "Severe Security Exploit", and when its a Mozilla bug, its a "Privacy Leak"...

      Umm, maybe because this bug isn't severe? It only lets a malicious site find out what URL you visit immediately after leaving the site. I'm much more concerned about IE's policy of allowing sites to read from and write to the clipboard than I am about this bug.
    • I'd define the terms thus:

      Privacy leak: lets someone else see what I'm doing or where I'm going. Does not let them see into my system.

      Security exploit: lets someone else see the contents of my HD.

      Severe security exploit: lets someone else *manipulate* the contents of my HD, pilfer my credit card number, or something else on that order.

    • Hmm. Take a look at the few posts above yours. Several of them describe how to fix the problem. Immediately. All you have to do is hack the prefs.js file, restart the browser and you're all set.

      Now explain to me how you could do the same thing with IE.

      I'll not be holding my breath....

    • Nothing gets my goat more than having crappy software shoved down my throat with a "and you will like it" to wash it down.

      I'm tons more willing to cut some slack to a free and open source project for a minor issue than to let off some corporation responsible for riddling my machine with security problems I can't uninstall-- and routinely refuses to fix ina timely manner.
    • by Anonymous Coward
      The poster asks:

      > But why is it when its an IE bug, its a "Severe Security Exploit", and when its a Mozilla bug, its a "Privacy Leak"...

      And it is currently rated as "Score:5, Insightful".

      I fear that Slashdot's moderation facility is being used by Microsoft as another FUD tool. While some posters try to moderate honestly, Microsoft astroturfers moderate each others' posts up, thus increasing their karma, and giving themselves more power to moderate.

      There is no objective basis by which the above post could be considered "insightful".

      In fact, the above post is completely stupid.

      The post suggests there is something wrong when some IE vulnerabilities have been rated "Severe", while this Mozilla vulnerability is just rated as a "Privacy Leak".

      Let's consider that.

      Should this Mozilla problem be considered as "severe"? Hardly. As others have pointed out, providing the URL of the site you are going to is not that different from what all browsers have always done when they provide the URL of the site you came from. In fact, the problem is so minor that I am not even going to bother installing the fix until the next browser release comes out. When referring to this problem, the words "Privacy Leak" are, if anything, too strong.

      On the other hand, let's consider some of the _19_ currently unpatched security holes in IE [pivx.com].

      Here are some samples:

      > Who framed Internet Explorer
      > Description: Cross-protocol scripting, arbitrary command execution, local file reading, cookie theft, website forging, sniffing https, etc.


      > MS JVM native method vulnerabilities
      > Description: A collection of at least 10 different vulnerabilities in the MS JVM, escaping the sandbox, local file reading, silent delivery and execution of arbitrary programs, etc.


      > WMP Stench
      > Description: Silent delivery and installation of an executable on a target computer


      > Java XMLDSO base tag
      > Description: Arbitrary local file reading.


      > delegated SSL authority
      > Description: HTTPS spoofing, man-in-the-middle attacks, etc.


      > document.domain parent DNS resolver
      > Description: Improper duality check leading to firewall breach


      > CTRL-key file upload focus
      > Description: Local file reading, downloading and executing arbitrary code.


      Arbitrary command execution? Local file reading? Escaping the sandbox? HTTPS spoofing? Firewall breach? Should any of those be considered "severe"? You betcha!

      In fact, of the nineteen open security holes in IE, nine of them allow binary executable code to be run on your computer.

      So clearly, the original poster is an idiot. Objectively, his post should be rated "Score:-1, Troll".

      I would say that the posters who moderated his post up are even bigger idiots, but I don't believe that to be the case. Instead, I figure they're probably professional liars, being paid by Microsoft.
  • bug? (Score:4, Interesting)

    by bilbobuggins ( 535860 ) <`moc.tnujtnuj' `ta' `snigguboblib'> on Sunday September 15, 2002 @10:52PM (#4263501)
    I don't understand how this is a 'bug'.

    First of all, this does not allow someone to track where you're going but rather where you went. I know that sounds like nitpicking, but really it's the difference between a bug and a correct protocol implementation.

    The method described is to check the referrer on requests sent to a particular server after the user has left a page on that server. Surprise! the referrer is now their current location i.e. where they went after your site.
    Would you expect any different?
    It's matter of micro-seconds and request timing.
    Ok, maybe they could make sure all requests generated by an 'onunload' event are handled before the request to the following page, but personally I would consider that a judgement call and not 'bug'.

    Also, I've noticed people here don't seem to give a hoot that your entire history of where you came from can be far more easily tracked!

  • Opera lets you turn off the referrer entirely. I always use that, for privacy reasons. Besides, it lets me use the Bugzilla links that people say are designed to be unaccessible from Slashdot :-).

    What good is the referrer supposed to do, anyway? I always found it disturbing to be able to see in my logs which IMAP folders people use with their webmail.

The use of money is all the advantage there is to having money. -- B. Franklin

Working...