Ratio Vulnerability in BitTorrent Discovered
An anonymous reader writes "The "vulnerability" has been tested on all the major torrent trackers that use the torrentbits source code. The idea is that you will sniff your torrent info using the HTTP Analyzer and with Firefox you will update your stats to the tracker being identified as a client."
There are any number of parties who will headline "Vulnerability in BitTorrent!" and cound on most readers never bothering to get the facts.
Lacking <sarcasm> tags,
As much as many people will ask if disclosure was a good idea in this case, it's important to remember that if one person can find this vulnerability and make it public, an unknown number of people could have found it and be making use of it in the background. The functionality of BitTorrent depends on clients seeding copies of the file back into the network after having downloaded, and a vulnerability like this in a significant amount of trackers could easily cause serious damage to the operation of many torrents.
Business Voyeur
According to the IE7 thread, the only way to force fixes is by disclosing vulnerabilities. Goose, gander etc I suppose
Unpretentious Sydney reviews by unqualified Sydney reviewers
I would imagine that setting up a small script that bumps up your uploaded amount by a few hundred MB every now and then would be very hard to detect. Certainly more difficult than spotting someone who just uploaded 10GB out of nowhere (as in the example).
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
Actually, this is a common concern among security folks. "If we announce a bug, those who don't patch are going to get pwned."
Only security researchers generally don't use the term "pwned" in their press releases...
I've been studying BT for over a year now, and this problem is very obvious and well-known. So, anyone who claims that they shouldn't have posted this because it's going to kill BT is wrong. They shouldn't have posted it because it's obvious to anyone who reads the BT protocol. You can just modify the source code and send a random real from zero to one, plus one, times however much you've downloaded and you've got a share ration between 1 and 2. Simple.
The simplest and best solution to this problem is the one that idiots (especially BT client developers like Bram Cohen and the Azureus dev team) tend to dislike the most: instead of forcing people to be cooperative by enforcing seeding requirements either in the client or at the trackers, simply recognize that swarming creates an inherently competetive environment, as everyone is really only concerned about their download and SHOULD only be concerned about their download, and let people use the most unscrupulous tactics they can think of to game the system. The way it will play out is that people will end up with a share ratio close to 1. The swarms become like little free markets: if you have a valuable piece, you can agree to trade for a lot of data. If someone breaks their agreement, you ban their IP address for a while. If you're willing to upload twice as much as you request from others, EVERYONE will want to trade with you.
If you do the math and economic analysis, everyone ends up trading on a 1 for 1 ratio, seeds only have to upload when there's very few peers (they simply require 2 bits from you for every bit they upload, that way people will only rely on seeds if they can't get a piece any other way, specifically, if the availability of the piece is zero), and no one other than the individual or group publishing the data needs to seed. BT was never meant (whether Bram Cohen realizes this or not) to shift the responsibility of serving from the publisher to the clients, it was meant to reduce the amount of bandwidth needed to publish data.
The current system is like socialism. It needs to become more like capitalism, and I'm not even a laissez-faire capitalist! Why no one realizes this is beyond me.
Since eMule is more appropriate than eDonkey for the eDonkey network.
See my blog for my free opinions.
thirded. Apache isn't the only httpd that makes logs, and (2) something still has to read and make sense of the logs.
Any task can be called easy if you don't know what the fuck you are talking about.
Yes, it's amazing how opinions on that sort of thing changes for so many people when the product in question isn't "their's" but "ours".
..I caa't think of a but. It's just hypocritical.
I would say that it's hypocritical but...
I'm going to be a bit vitriolic, but you deseve it.
Was it really a good thing to make this public?
Yes, it was. This way, all people will know about the vulnerability, and we can get around to design something better - instead of it spreading among leachers and not to the general population.
Won't this cause a new wave of leechers?
That's part of the idea. Bittorrent is an open protocol, and when everyone knows about the vulnerability - it's a tad more pressure on various developers to remove the design flaws.
A lot of trackers are built on torrentbits.
So fucking what? Do you want to tell mother nature not to send a hurricane against New Orleans, because it will be a disaster? No, you won't.
What you will do, on the other hand, is try to design something that works. If it doesn't work, it's back to the drawing board. Keeping silent is what companies such as microsoft think is a good idea. It is not. It's a hellish bad idea. You'll have various scum abusing the vulnerability without everyone knowing about it. You'll have admins having these kind of thing biting them in the ass without being prepared for it.
Publishing this kind of information, even though when it's a deep design flaw in the trackers such as this, makes it easier to cooperate and eliminate the fuckups. Keeping silent about it doesn't do any good at all.
Did you know that various worms abused sendmails "debug" command in eariler years? And that it gave you a root-shell on the mailserver? No? Well, it wasn't very smart - and a lot of people knew about it, without giving it much publicity. It was way larger than this idiotic flaw, but it was your idiotic idea about 'shutting up about it' that caused the havoc.
One should always disclose security flaws. No exception. Even though if hundreds of millions will be caught in the middle. It's the only way to ensure that it'll be fixed, and that everyone will know about it - at least everyone that cares enough to follow the news.
Now onto an idea on how to fix this garbage. It's not a bug in the bittorrent protocol, as it won't affect how much various people send to eachother. It'll mainly affect statistics on various sites, and whether you will be banned or not. Personally I think the solution is for every client to upload how much their peers have sent them - and for the peers to check that amount. Think of it as 'trusted third party'. If any of the peers disagree too much about the amount over time, they discontinue talking to each other - and the client that disagrees logs an 'objection' with the torrent-server. If we're talking several gigabytes of data, it should be very easy to spot by the administrators. Especially if it's the same peer that gets flak all the time.
Of course, this will be problematic when you think about NAT's, as various computers behind NAT-devices will check their internal IP, and not the external one. That, however, is not the responsibility of the trusted third party, but the responsibility of the peer. Unfortunately this will make things more difficult, but hell, it's a tradeoff in any case. This might be solved through in-band communication with peers telling each other who they think the other party is.
Ahwell. Enough ranting.
I would think that the vast majority of folks using BT to get "legitimate" downloads won't be using this hack (I must get this Knoppix ISO and not share!). Really, it just exploits the greed of the pirate community, for which I have little sympathy.
You could try the exploits, which only damages the system and will get you eventually banned from your favourite torrent sites, or you could just get half a dozen downloading and go to bed.
Phillip.
Property for sale in Nice, France
Let's assume that slashdot, every time you submitted a comment, included a variable that incremented the "number of comments you've made today". Let's call it "inccom=1" and lets say that in the code while it's processing your comment it just adds "total comments" with "inccom" and gets the total number of comments you've made today.
This would be a stupid way to measure the total number of comments because I could simply modify this value to 0 or -1 and make an unlimited number of comments every day. This would be a way of messing up the system. This would be an exploit.
So why is the bittorrent protocol doing (essentially) this?