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
