Re: KaZaA

["Nicholas C. Weaver" <nweaver () CS Berkeley EDU>]

David Krum wrote:
> My attention was first drawn to this when I noticed KaZaA launching popups 
> sourced from the local hard disk.  Surely these ads are running in the local 
> zone.  To use software that does this I have to trust them to audit the ads 
> given to them?

Then again, with KaZaA, you have to trust all the scumware and
leechware included in the client, which has in the past included
autoupdate programs controlled by third parties, see
http://www.cs.berkeley.edu/~nweaver/0wn2.html for one such example.

The other portions of real concern are just what a massive breeding
ground for potential worm attacks KaZaA represents:

A flaw in the server side of the client->server communication opens up
the potential for a very fast topological worm.  Each infected machine
contacts its neighbors, infects them, and the infection proceeds.
Time to infect the whole graph is a function of the longest shortest
path in this graph.  Since KaZaA is fairly well connected, it would
probably take about 1 minute to infect everything.

A flaw in either side could be used by a contageon strategy, where the
infection piggybacks in the normal communication process.  We really
don't know how fast it would spread, but the high connectivity of
KaZaA is not an encouraging site.

No flaw at all is required for the "bait" style worms we've seen in
the past, such as W32.Benjamin.  A smarter bait worm which monitors
the query stream and masquerades as files queried, and matches their
size, would be much more effective.

There is nothing which can really stop a novel bait worm before AV
updates and the like can be pushed out, short of not transmitting
executable content through the Peer to Peer network.  Voting up
schemes could be foiled by having the worm vote for its compatriarts,
while voting down can be foiled by upping the diversity of MD5
signatures which the worm will present for any given file.

If one is concerned about security, one either avoids using KaZaA or
the other file trading programs entirely, or at least avoid receiving
any executable content.

-- 
Nicholas C. Weaver                                 nweaver () cs berkeley edu