[18120] in bugtraq
Re: cache cookies?
daemon@ATHENA.MIT.EDU (Szilveszter Adam)
Mon Dec 18 16:22:29 2000
Mail-Followup-To: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu>,
BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-Id: <20001216011753.A2400@petra.hos.u-szeged.hu>
Date: Sat, 16 Dec 2000 01:17:53 +0100
Reply-To: Szilveszter Adam <sziszi@PETRA.HOS.U-SZEGED.HU>
From: Szilveszter Adam <sziszi@PETRA.HOS.U-SZEGED.HU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <p05010401b65e0e9ed22a@[192.168.1.93]>; from nazgul@SOMEWHERE.COM
on Thu, Dec 14, 2000 at 12:58:55AM -0500
Hello everybody!
After reading the news release, the pdf file (which I could download
alright although I am definitely not an ACM member:-) and trying the exploit,
I thought I would throw some thought into this discussion...
First, the example exploit gives some interesting results.
On WinME with IE 5 build 5.50.4134.0100, it almost works but upon loading
the page for the first time, only misses are reported (maybe one or two
hits) upon hitting reload, the ratio is changed, almost all hits. After
flushing the disk cache, the result is as expected ie again lots of misses.
However, IE gives me stack overflow errors:-) (maybe stuff for Georgi)
(Netscape also complains about JS errors BTW)
However, with Netscape 4.75 on the same platform, if disk cache and memory
cache is turned on, I get at least 10 but sometimes 15 misses upon
reloading the page. This does not change no matter how many times I reload.
If I turn off disk cache but leave memory cache on, results are not
significantly different. If I turn it off alltogether, of course there are
no hits.
On FreeBSD 5.0-CURRENT, with Netscape 4.76 for Linux and with only memory
cache turned on, I get almost full hits upon the first reload, maybe
one-two misses. However, after closing and restarting, no matter what the
settings were, I always had only misses upon first loading, only after
reload did I get hits.
(Testing was done on a K6-II 450 and on a PII 233, with 64 and 128 megs of
RAM, respectively, both of them connected to the university LAN at 10Mbps.
No second-level cache was involved.)
However, there are some other remarks that should be made IMHO.
1) The paper argues that turning off caching in the browser would have
catastrophic consequences. Well, it depends. Exactly in the environment
where this exploit works best (ie LANs, DSL) the speed generally is
acceptable to download the whole page again if needed. The pages that
profit from caching most are the ones that are entirely static and reside
on a slow network link, but these days most popular pages have highly
dynamic content and ads etc and those are reloaded anyway. I would even say
that under our circumstances, most download time actually is spent waiting
for the many banner ads to load. These will not be cached. Obviously, the
slower the link, the more significant caching becomes, but in LAN
environments one can decide if turning off caching is worth the
discomfort.
On Netscape, turning off disk cache and only leaving memory cache active
can also mitigate problems somewhat, assuming you actually *close* Netscape
after a session:-) (And in my measurments, running only on memory cache vs
memory plus disk did not show any performance problems, but YMMV)
2) This exploit would not work well with modem users, particularly on slow
lines. While you might argue that they need caching the most and that
checking the URLs you want does not take up much time, it is likely that
the URLs you would be checking would belong to some popular site. These
sites are often busy and unable to answer immediately. Also, checking URLs
does take longer than on a LAN. However, on a modem no network activity
goes unnoticed. While on a LAN it does not matter if you send out 1000
bytes, on a modem it does if eg it does not allow the line to close or
attempts to open it. In Europe, and in particular in Central-Europe, most
users
outside of higher ed & government are on modems and they have to pay by the
minute for access. So many do not even download the images let alone banner
ads. They would almost definitely notice this esp if they were using (as
many do) not the latest in modem technology. (meaning 33,6kbps here.)
3) The point that exploring secondary-level caches can make things worse is
somewhat moot because in order to actually be able to discover eg the
internal network structure, you would have to make all clients connect to
you within a reasonable time frame. Even when sending out a chain letter to
everybody (say about a new Pam video) this is not guaranteed to work. Also,
the assumption that organisational units use shared secondary caches
is not always true.
4) As for DNS cache attacks, I am not sure which browsers and other
programs have one but not all of them do. (Which is true for Java/JS
support as well. Just consider eg Mozilla, which is becoming more popular,
but it does not support Java on platforms other than Windows, Mac and
Linux for the moment.)
5) The suggested "cure" by the authors is to do some sort of "domain
tagging" to itmes in the cache, so that only machines from the sender's
domain could request them, like it is the case for "normal cookies". Apart
from the fact that it is not fool-proof even for normal cookies, because eg
some countries only have a TLD and therefore two dots in the domain
specification are enough for them, while others already implemented
secondary TLDs as well (like .com.au) and in these cases setting a cookie
and giving access to it to the domain part of the setter containing two
dots would actually open it up to the whole commercial Internet in
Australia, this would not work for the following reason:
Consider a site that has say a logo of a partner site on it *but* this logo
is not stored locally but rather is a link to that other site and the logo
is there as well. So, by loading the page of Site A, which has a logo from
Site B embedded in it, Site A will check if you have that image in your
cache, in which case it will gladly use it. But if we implement "domain
tagging", Site A could not request this image from the cache since it is from
a different domain. This would put a further obstacle to linking... thus
creating perhaps more hardship than it solves. Consider that on portal
sites there is a lot of linked-in content.
I would suggest instead that disk caches normally not be used, because then
at least these cache items would not be persistent across sessions but
provide the necessary boost during the session using memory cache. This is
only a partial solution but if you close the browser often enough (which
you should do anyway if you visited a sensitive site because of possible
cross-site scripting problems) then it is not as bad. It is possible with
Netscape, I do not know if it is under IE or Opera.
This much from me this time, thanks for the patience:-)
/* Powered by FreeBSD 5.0, the Power to Serve and
* Radio Pyramid, Bishkek, Kyrgizistan (http://www.pyramid.elcat.kg)
* /
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
