155571 - kcookie.netscape.com cookie imported from ns4 appears to slow Mozilla down

Status: RESOLVED WONTFIX

(Core Graveyard :: Profile: Migration, defect)

Description

[Glenn Moeller-Holst]

I have been a Netscape user for many years now, and I have the experience that 
Netscape browser are quick.

But for the last year or so I have encountered a special kind of cookie, that 
appear to slow Netscape browsers down.

In the rest of this description, I will give you the information, I have 
collected information about the cookie in question.

with kind regards,

Glenn Moeller-Holst

--

Problem
For now I have just found the cookie problem on Apple MacOS 8.6-9. I have not 
looked in cookie-files on Microsoft Windows or Linux OS's.

E.g. with Netscape 6.22 I have experienced that the browser stand still or breaks 
down, when I try to quit Netscape 6.22. The cause might be this Cookie:
***
kcookie.netscape.com	FALSE	/	FALSE	4294967295	kcookie	<script>self.close()</
script><script>do{}while(true)</script>
***

Please note: The DNS-name "kcookie.netscape.com" does not exist.

In Netscape 4.77 it got the browser to stand still.

--

Removal of the problem symptom
*Quit Netscape. Eventually restart the computer to make sure, that Netscape does 
not overwrite the Cookie-file later.

*Find all Cookie-files og delete lines containing: "kcookie.netscape.com...". The 
cookie in question, are nearly always at the top of the file.

--

I have tried to insert the "kcookie.netscape.com..."-cookie again to test, if the 
problem reappears, it does not. So something else must be involved, but I do not 
know what.

On two distinct 2 computers, the problem was solved be removing the 
"kcookie.netscape.com..."-cookie.

--

Cookie file "cookie.txt" eller "MagicCookie":
"
# Netscape HTTP Cookie File
# http://www.netscape.com/newsref/std/cookie_spec.html
# This is a generated file!  Do not edit.

kcookie.netscape.com	FALSE	/	FALSE	4294967295	kcookie	<script>self.close()</
script><script>do{}while(true)</script>
..."

--

By searching on the internet:
http://www.google.com/search?hl=da&sa=G&q=%22kcookie.netscape.%2Bcom%22
This was found:

http://archives.neohapsis.com/archives/sf/www-mobile/2001-q2/0030.html
http://www.google.com/search?q=cache:archives.neohapsis.com/archives/sf/www-
mobile/2001-q2/0030.html
"...
From: Ric Steinberger ([e-mail])
Date: Sun Apr 22 2001 - 12:41:52 CDT
...
There's a 'nasty' little cookie from kcookie.netscape.com that always shows up in 
a Netscape cookie folder, regardless of whether you ever visit the Netscape site
..."

--

The cookie "kcookie.netscape.com..." is also found here:
http://www.oreilly.com/catalog/jscript4/errata/jscript4.unconfirmed
http://www.google.com/search?q=cache:www.oreilly.com/catalog/jscript4/errata/
jscript4.unconfirmed
"...
The code works by itself.  I notice that when you mix javaScript code with 
vbscript code in a .asp page there are some funny results.  Below is the results 
I found.
...
kcookie.netscape.com    FALSE   /       FALSE   4294967295      kcookie <script>
location="."</script><script>do{}while(true)</script>
w2d059  FALSE   /       FALSE   1012228498      myvar  var2=vbexpl2:undefined&
var1=vbexpl1:undefined&var1:jsexpl1&var2:jsexpl2
..."

Comment 1

[Olivier Cahagne]

*** Bug 155573 has been marked as a duplicate of this bug. ***

Comment 2

[Glenn Moeller-Holst]

Actually,

Bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=155571
is an earlier version of bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=155573

I am sorry for the inconvience

kind regards,

Glenn

Comment 3

[Stephen P. Morse]

There is of course no such site as kcookie.netscape.com.  Instead this is a 
fictitious cookie that, as you can see, contains bogus javascript intentionally 
designed to loop if ever executed.

The key point here is that the cookies file should never get executed.  However 
there were some security attacks whereby a site would store some nasty js code 
in a cookie and then, using a loophole in the browser, get the cookies.txt file 
to execute.  When that happens, the executing js code had all the permissions of 
a file on the local machine and could do a lot of nasty things that js code from 
a website could not do.

To fix this flaw, we closed the loophole that was allowing the user to execute 
the cookies.txt file.  But we went a step further and wanted to make sure that 
no other such loopholes could do any damage.  So we added this cookie to the 
head of the cookies.txt file.  Now if any future attacker figures out another 
way to execute cookies.txt, he will immediately hit the kcookie (which we always 
put at the head of the file) and loop.  Whatever cookie he set would never get 
executed because we would never get past the kcookie.

The kcookie is created every time that the cookies.txt file is written out and 
is stripped off every time the file is read back in.  So obviously there is code 
that does this writing and stripping.  But if you do a search through the 
open-source files of mozilla, you won't find any reference to 
kcookie.netscape.com.  That's because the mozilla code does not use the kcookie.  
It was only in the 4.x codebase.  If you create a new mozilla profile and look 
at its cookie.txt file, you will not see a kcookie.

However you reported seeing one, so I checked a bit further.  I discovered that 
if you migrate a 4.x profile into mozilla, the kcookie will get migrated as well 
(I just tried that).  So I'm willing to bet that you are using a migrated 
profile.  Am I correct?

Now as far as your claim that the kcookie is slowing down the browser.  The only 
way that could be possible is if the cookies.txt file were being executed (the 
security bug).  I'd be very interested in knowing if that is happening because, 
if so, we need to find out why.

In any event, the fact that the kcookie is being migrated is a bug in the 
profile migration code, so I'm reassigning.  I'm also marking this bug as 
security-sensitive (for obvious reasons) which means that the only people who 
will be able to access this bug are those on the security team as well as the 
reporter and anyone on the cc list.

Comment 4

[Stephen P. Morse]

I found the reference you cited quite amusing.  Here is more of the quote:

 There's a 'nasty' little cookie from kcookie.netscape.com that always shows up 
 in a Netscape cookie folder, regardless of whether you ever visit the Netscape 
 site. ... Undoubtedly, AOL has had a hand in this strategy. In any case, it's
 a privacy violation, IMHO (so what else is new).

Here we are, trying to protect the user's security by adding this fictitous 
cookie to thwart a possible attack, and our critics accuse us of violating the 
user's privacy.  So what else is new.  ;-)

Comment 5

[Glenn Moeller-Holst]

Thank you for the explaination about the "fictitious cookie".

Qoute from [e-mail] 3 Jul 2002 07:22:32:
"...However you reported seeing one, so I checked a bit further.  I discovered 
that if you migrate a 4.x profile into mozilla, the kcookie will get migrated as 
well (I just tried that).  So I'm willing to bet that you are using a migrated 
profile.  Am I correct?
..."

Yes, a kind of, I use all these browsers with the same profile to share bookmarks 
and cookies:
Netscape Communicator 4.79
Netscape 6.23
Mozilla 1.0

Qoute:
"...Now as far as your claim that the kcookie is slowing down the browser.  The 
only way that could be possible is if the cookies.txt file were being executed 
(the security bug).  I'd be very interested in knowing if that is happening 
because, if so, we need to find out why...."

I do not for sure, that the cause is execution of the cookies.txt-file. FYI: On 
my MacOS, it is called MagicCookie.

Several times (maybe more than 5-10/year), I have solved the slowness-symptom, by 
quitting the currently used browser and deleting the kcookie. I have also from 
time to time, just quitted the browser and checked if it solved the problem - it 
did not, as far as I can remember.

From some time ago, I can not remember which one, Netscape 6.2x or Mozilla 
1.0beta just kept "freezing" the computer. Then some days/weeks later, I 
remembered the kcookie problem I encountered earlier. Then I removed the kcookie, 
and the browser worked again.

My settings in all browsers:
Disable Java
Enable browser Javascript (ECMAscript?)
When possible, I disable image-looping

If I encounter the problem again and have more information, I will write again.

regards/Glenn

Comment 6

[Mitchell Stoltz (not reading bugmail)]

My guess is that the kcookie is not what's causing the slowness - but it's
always possible.

Comment 7

[Bradley Baetz (:bbaetz)]

Change the thing in the while loop to do a dump("in prefs.js"), and then enable
dump for the release build (I cna't recall what hte pref name is for that off hand).

Where does the dump output go on a mac build?

Comment 8

[Greg K.]

Glenn, please be aware that sharing profiles between Mozilla and Netscape builds
is not supported and may cause problems. See the Release Notes for either browser.

Comment 9

[Matthias Versen [:Matti]]

The MAC classic builds are discontinued