Researchers have found a flaw in Mozilla-based browsers that springs data on the Web surfing movements of users.

Head researcher at Neopoly Sven Neuhaus said the bug, first discovered in May, is a serious privacy issue.

In a demonstration of the flaw, Neuhaus says it exposes the URL of the page a user is viewing to the Web server of the site visited last, allowing a Web site to track where a viewer goes next regardless of whether the URL is entered manually or via a bookmark.

"This bug is still present in the Mozilla 1.1 release... It's been three months," Neuhaus said in a plea for a fix on Bugzilla, the site used to track vulnerabilities in Mozilla releases.

It affects Mozilla browser versions 0.9x, 1.0, 1.0.1, 1.1 and 1.2 alpha; Netscape 6.x and 7; Galeon 1.2.x and Chimera 0.5.

Mozilla users are urged to disable JavaScript as a temporary workaround until a fix is issued. The flaw exists in the "onunload" handler which loads an image from the referring server about a user's surfing movements.

I asume it would include K-Meleon too??? since it is based on 1.1

It's hard to tell if ThatDude's being genuinely serious and concerned for fellow K-Meleon users here, or he's just yanking the chain again, however I'll err on the better side of my judgement, and for the moment give him the benefit of the doubt.
The problem you mention here is also the same one mentioned here:
http://www.net-security.org/vuln.php?id=2039

There is a page listed to demonstrate the privacy flaw in action, however I wasn't able to pull it up. Maybe somebody else can.
It is: http://members.ping.de/~sven/mozbug/refcook.html

Good work ThatDude. Now isn't that better than trolling... ;-)

One suggested workaround for this is:

Add the line

user_pref("capability.policy.default.Window.onunload", "noAccess");

to your user.js file.

We will ensure that our next beta includes either a patch or a workaround for this security hole.

Thanks guys. I did confirm this on 0.6. The fixes listed here and on the other site both work to foil the breach.

user.js
user_pref("network.http.sendRefererHeader", 0);
user_pref("capability.policy.default.Window.onunload", noAccess");

That was simple enough. Is there any real purpose for such a feature that possibly the Mozilla coder purposely put it in?

Is there any real purpose for such a feature that possibly the Mozilla coder purposely put it in?

"capability.policy..." is a general mechanism to enable/disable JavaScript functions.
It's also used to disable broken or unfinished functions or for things like popup-blocking.

"network.http.sendRefererHeader" is a privacy feature that some people already used, but disabling it may give you problems with certain sites that protect their downloads against direct linking.

So then it really isn't a "security" issue but a sometimes desireable feature. Interesting.

Most all browsers send referer data to a site when you clicked on a link to get to the site. There is a flaw in the mozilla code which allows the use of it for purposes it was not intended for, this is where the security risk comes in.

The only time it is a problem is if the url (As it appears in the url bar) contains information that you do not want another server to see. Since it is normally a security risk to have sensitive data passed with the url anyway, this is not much of an issue, especially since it only gets the data on the next page, not anywhere you go from there, or any info you may submit on this page. The only reason that I have heard so far whaere this could be a problem is if you have hidden pages on a server you don't want other people to see. But then why aren't these pages secured to begin with?

Personally I leave javascript and the referer turned on. So what if someone goes out of their way to set up a javascript that only targets a small percentage of visitors to get the url of a page I go to next. I secure anything I don't want people to see.

A number of security issues have arose since the release of KM 0.6 . Yet the main page of KM shows nothing about them: A buffer overflow of libpng, and a number of less severe volnurabilities.

KM seems to be a program with a long release cycle. OK. But should the users of the stable version be left in the cold?

Maybe version 0.6.0.x are in place: for major security fixes in the stable branch.

But most important of all: acknowledge the problem! Whenever there is such volurability, publish a news item for the users of the stable branch of what they should do. Maybe it should simply be the simple workaronds mentioned above.

"KM seems to be a program with a long release cycle. OK. But should the users of the stable version be left in the cold?"

The problem mentioned has really only been known about for a short while, which is why there has suddenly been mention of it. The flaw affects v1.1, and any previous versions of Gecko/Mozilla prior to it (this you would have read on the page I mentioned earlier in the thread). So in effect, it not only affects the "stable" version of K-Meleon (0.6), but it also affects the current and any previous beta versions as well, and as Andrew has mentioned, this problem will be rectified in due course. You are not being "left in the cold" about anything (especially if you were just reading and replying to this exact same thread). Besides, the problem is not a "biggie", so don't sweat it.

What about the buffer overflow in libpng? I know beonex have issued a fixed build (with a fixed libpng) to solve that. I figure that libpng is used by gecko (to shoow png images) and thus by KM as well. This is over a month old, I believe. Long enough to write a number of exploits.

Another volunrability I recall is something discovered shortly after mozilla 1.0 was out. It has soemthing to do with a script running on one frame that can probe the network as if it were from another frame. They demonstrated a nice exploit that bypasses NAT and explores web servers in a NAT-ed network.

"Another volunrability I recall is something discovered shortly after mozilla 1.0 was out. It has soemthing to do with a script running on one frame that can probe the network as if it were from another frame. They demonstrated a nice exploit that bypasses NAT and explores web servers in a NAT-ed network."

Hmmm, I wasn't aware of that one, I'll have to search around to verify it.

This one mentions NAT, could it be the one you are referring to:
http://www.securiteam.com/securitynews/5HP0Y007PK.html