Slashdot Mirror
Privacy Leak in Mozilla and Mozilla-Based Browsers
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."
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:
n lo ad", "noAccess");
:)
user_pref("capability.policy.default.Window.onu
You won't miss those ununload events anyway
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
youre right, its not news. it would only be news if it was in internet explorer, correct?
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.
THE GOOD HUMOR MAN CAN ONLY BE PUSHED SO FAR
Bart Simpson on chalkboard in episode 2F18
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
- (c) 2018 Hank Zimmerman
well, I think that you solved your own problem. If you don't need the extra features, don't use the alpha builds, they ARE unstable by nature. Use the 1.0x series, that is stable.
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.
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.
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.
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.
> ...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.
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.