Slashdot Mirror
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."
now this. I can't believe it, my world is falling apart!
Unpretentious Sydney reviews by unqualified Sydney reviewers
I can't wait to see my pornbits ratios go through the roof! j/k
Guess now I really have to start seeding files. Thank you for spoiling it for me.
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
The way I look at it is this:
Step 1. Load site logs
Step 2. Do a search for these entries
Step 3. Ban any cheaters
I'm sure this it should be pretty easy to tell fake entries from real ones as I'm guessing that the tracker software, with a known IP address, is the only thing that should be accessing that url.
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
for promoting FF, but one of the steps in that list should be: set FF as the default browser ;)
You can't handle the truth.
Seriously, I thought this was already widely known. All info from the client to the tracker is sent with basic HTTP GET requests. You could fake your ratio with a simple php script. Well, maybe even by just typing the info in your web browser, however I think the urlencoding would be a problem.
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.
This is not a vulnerability .. it's by design.
The statistics reported to the tracker by the client were never meant to be used for things like enforcing ratios because they TRUST THE CLIENT. But there's simply no other way to collect statistics such as amount uploaded.. if the client lies to you (which is what this "vulerability" is exposing), there is little you can do to protect yourself.
It's TRIVIAL (a 1 line change, or if you want to make it a parameter, a 4 line change) to modify any python open source client such that it 'amplifies' the ammount you upload by 10x or 100x. Then you don't need to do any HTTP sniffing, your client can just lie for you.
Now, there is a way to block this author's method because he doesn't amplify the upload, he creates a step-change in the upload ammount (which can be caught on the server side.. if it's been the same ammount of time since the last check-in, but suddenly his cumulative upload ammounts tripled, you're likely being abused). However, using my 'amplifying' trick from above, this is much trickier to detect. Perhaps you measure the client's upload speed on the website and record it to the database, maybe even double it just to be safe.. so you KNOW this client can only do 60 k/sec or whatever. Then when the client reports in stats, you take the time since the last check-in and you calculate his approxomate 'instantenous' rate. If this rate is higher then the upload rate you previously decided was this client's ceiling, then he's lying to you.
The above method is not foolproof, but it would likely be better then the nothing we have now. It was really only a matter of time this surfaced.. and I'm amazed it took this long.
--kRYPT
(author of burst! and MakeTorrent)
DJ kRYPT's Free MP3s!
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...
This is nothing new, there's been client hacks for this for quite a while (http://www.00de.com/), there's also been ratio faking programs out for quite a while as well. So I really dont see anything additional that this 'xyflar' guy has added besides posting what's been known to pretty much every torrent user as well as pretty much every torrent site that uses ratios.
Your hair look like poop, Bob! - Wanker.
Anyone who has even so much as glanced at the protocol specification can see that the client is trusted to return an accurate count for how much it has uploaded. This wasn't a "disclosure" or a "vulnerability announcement"- it was a statement of the patently obvious.
The problem is not with BitTorrent. The problem is with BitTorrent trackers and sites which trust that value returned by the client. There are dozens of open-source clients, including the original- and all it takes is adding one operation that multiplies the real upload by whatever number you desire.
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.
How did this pseudo-intellectual first-post get modded insightful? You clearly don't understand how the BitTorrent network is designed. Clients evaluate only how much data they receive directly from another client, and how fast. Nothing else factors into their decisions of who to upload. There is absolutely NO mechanism for the client to query the server to see how much you've uploaded, nor is there even a way to ask other clients. Why? Because both sources would be unreliable. Each client CAN only rely on direct "experience", unless they're engaging in a reputation system of their own hacking- if they are, best of luck to them, Bram wasn't an idiot for not trying that.
The "vulnerability" only affects trackers which "enforce" an upload ratio, and only to the extent of letting people bypass that ratio. Ratios is a concept that is pretty stupid with BitTorrent. The more you push back, the more you get, unless there is plenty of bandwidth. About the only "benefit" I see to ratios is that it might keep files available with seeds longer.
I hear a lot of crying about leechers on BitTorrent, but the network is self-regulating. Don't upload? You won't get much back. I think the perceived problem is also because reporting of the stats is unreliable- in the case of Azureus, for example, I can download a big file, upload 3x as much, and then if I get a connection error when my client stops, I "loose" all that uploading. I then look like a leecher, when it is exactly the opposite.
Please help metamoderate.
Being a formet BT tracker admin we knew of this well over a year ago.
Just download the original client and change the source code if you want to automate the process.
That's great and all but I think google have enough bandwidth.
Have you metaroderated recently?
It is very, very, very easy to detect cheaters on private torrent sites -- which are the only sites where ratios really matter anyway.
Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded. Think about it for more than three seconds and its rather obvious. Every single client reports their usage to the tracker. Every byte you upload must have been downloaded by another client, who also reports their usage.
And hash fails are counted as downloads by the client, so thats not a factor.
If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
Granted, the situation becomes worse when multiple people are cheating, but it's not too hard to track users who are on multiple torrents and pick out usernames who always appear to be on the torrents with the discrepancies.
I've seen it happen on private sites before, and it will happen again.
The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Ratios is a concept that is pretty stupid with BitTorrent.
Right, stupid as in "people routinely saturate their downstream when ratio is enforced because everyone keeps seeding after having downloaded" and as opposed to smart, non-ratio trackers as in "people often get crappy speeds especially when they're on asymmetric connections because everyone kills the client after having downloaded the file".
BT is kind of self-regulating, upload more and you download more. But the self-regulation only goes so far and offers no incentive whatsoever to actually seeding files. Since a vast majority of the peers are on asymmetric links (e.g. ADSL), there obviously is a need for pure seeds to keep network speed at a high level, because otherwise the maximum network speed would be limited by the total upload speed of the asymmetric links.
Switch back to Slashdot's D1 system.
No, it wouldn't. The only thing this has any effects on, are tracker stats.
Bittorrent clients upload to who uploads most to them. And then they add a certain amount of randomness so that they get to try different peers. They don't care about the stats from the tracker, and neither should they, as they can be easily forged anyway (just change a line in your favourite bittorrent client and recompile).
If the bittorrent protocol was so brittle as to care about easily forged information, it would never have worked as open source software anyway.
So why do people care about trackers stats? Well, some people like to publish them (e.g. to make leechers ashamed). Some are nazis, and want to block leechers from their trackers. And some go beyond nazis, and want to block multi-tracker clients, etc, because it disturbs their tracker stats. This "vulnerability" is only a vulnerability to the two last groups...
oh, you've got to understand -- posting a coral cache link isn't something that's supposed to be well thought-out with some sort of reason to believe that it will improve access to the site. it's just something you're supposed to feel obsessed and compelled to post. just post the coral cache link without thinking. coral. post the coral. no! DON'T THINK! JUST POST! CORAL! POST CORAL! DO IT!
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.
What a wanking piece of haughty, uninformed bullshit! How this got modded up to +4 is beyond me. Bram Cohen has realized this from the beginning, and all client authors understand it as well. The design of the BitTorrent protocol is and always has been grounded in the economic principles of the free market. Seeding requirements are *not* enforced in the official client or tracker. Clients only upload to people who upload to them, and if people break their agreements they *do* get banned.
Your suggestion requiring uploads to seeds is stupid, because people would be even *less* likely to seed if it wasted their download bandwidth as well as their upload bandwidth (and twice as much of it too!). If you want to discourage downloads from seeds, simply make the seeds slow.
The idea of assigning economic values to individual pieces is already in the protocol implicitly; the economic value of a piece is inversely proportional to the number of clients who have it. If you have a piece nobody else does, you can upload it to anyone and get a piece in return, therefore that piece has high value. If everybody else has the piece, nobody will accept it in a trade. Therefore it's already in a client's best interest to grab the most rare pieces; additional incentive for this is not necessary.
If you have such awesome ideas about how to build a BitTorrent client that no one else does, then why don't you build one yourself and change the world? It's not that difficult; the protocol is simple by design. Otherwise, shut your trap about how stupid the people actually working on clients are.
The people who are not acting like a free market here are the writers of the *trackers* which trust reported uploads by clients (clients never trust these numbers for anything useful). Your entire rant is misguided and off-base; it should be aimed at the writers and users of ratio trackers, not the clients.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}