Hi all!
As anybody thought about how is it possible to hurt, or flood the GnuNet, and how to prevent it ? Is there anybody thinking about that ?
Somebody like the RIAA can start thinking about this and implement a virus, or a flooding macanism with dumb Gnutella clients just flooding the network.

Share your comments

TAS

Well,

I just found this paper that addresses this issue ...

Exploiting the Security Weaknesses of the Gnutella Protocol
http://www.cs.ucr.edu/~csyiazti/cs260-2.html

TAS

Mediaforce and Overpeer claim already to be flooding the gnutella network, - and I have no reason, not to believe them. The networks efficiency has clearly decreased in the past months and some searches only return 20-30% of the search results you would receive early this year.

PS: The methods described in the paper DO work, - despite the fact that it's 6-8 months old. Those security issues have been known for a while and the age of the papers it links to has not much to say. The gnutella network didn't change that much over time. GUESS, however, will solve some of those problems.

Gnutella has a number of vulnerabilities. Assuming you know a bit about Gnutella's workings, here are some things:

-- If one responds with a PONG with the port set to 80 and the IP address set to that of, say, CNN.com, a lot of people will start bombarding CNN.com with Gnutella Connect requests. Because of caching implemented, it will also take a while before these fake PONGs are removed from the network.

-- If one responds with a QUERY HIT, also with port set to 80 and an IP address that does not belong to me (like with the PING), I might also be causing people to attempt to download a file from a non-Gnutella client.

-- If one responds with a QUERY HIT, with the port and IP address of a Gnutella client user I don't like, I can cause his/her Upload slots to become full with short-lived requests (the file may or may not exist, hence short-lived because it'll abort with an 'File not found' error).

-- One can monitor QUERY HITs for files that are "blacklisted". If so, one could do the same as described above, and fill the upload slots with long-lived requests until full. If the agressor has access to multiple IP addresses, limiting X requests per IP won't protect against this.

-- One can inject the fake QUERY HITs into the network with ease, causing your result list to loose its quality. That is, any attempt to download a file from this "fake" list will fail (or alternativly, it is actively tracked).

-- One can "reverse" the HOP and TTL count in Gnutella messages. That is, each node is normally supposed to increase the HOP count and decrease the TTL count, so that a message does not live "forever". One could for example, reset the HOP count to zero (0) and the TTL to seven (7) (or a slightly higher value, like Hop of 1 and TTL of 6). This causes the message to live longer - at the end of a chain, it might even "double" the life of such message. Increasing the lifetime of messages on the network also increases the number of messages going though the network, thus causing a banwidth flux.

There are actually more things, but these are fairly easy to do with any existing, open-source Gnutella client. The problem is that each message on Gnutella is coming from a trusted source, even if that source is actually mallicious. These issues are also known to Gnutella developers (at least, those participating on the Gnutella Developers Forum), but only a few have shown interest in protecting end-users and others against these kind of "attacks".

Thanks.

Now that I looked more deeply in to this matter it really seems easy to cause damage to the network, not just the client using the software.

You said "...but only a few have shown interest in protecting end-users and others against these kind of "attacks".",
but it seems it can affect a lot of people and the network itself. Are any considerations been taken on the new versions of the protocol/software ?


TAS

Indeed, a lot of people are affected, if not all. Only a few developers have found a temporary solution against some of the things I mentioned. The best one maybe that BearShare implemented "Secure Channels", although this is a proprietary solution thus not shared with other Gnutella developers.

These issues have been presented to the GDF before (an online mailig list with many of the Gnutella Developers - see http://groups.yahoo.com/group/the_gdf/). Things were discussed for a while, but have pretty much been abbandoned in place of "innovative" features, such as increasing your overall search result quality.

In my opinion, they're giving the most important issue a low priority, since there's no discussion how all Gnutella developers can protect their end users, the network and third parties using a uniform security feature. And that worries me, because "who laughs last, will laugh loudest".