←back to thread

655 points k-ian | 3 comments | | HN request time: 0.748s | source
Show context
nneonneo ◴[] No.44302842[source]
Now I'm wondering: with the wide range of bittorrent clients out there, and the fact that many are written in unsafe languages, could it be possible for some of them to be exploited through a malicious tracker? It would not surprise me if some of these clients misbehave if fed malformed data from a tracker.
replies(7): >>44304020 #>>44304055 #>>44304380 #>>44305278 #>>44305546 #>>44306010 #>>44306382 #
1. cookiengineer ◴[] No.44306382[source]
Data is encoded via bencode so it's a byte wise format. Known malicious trackers usually inject stuff in the sense that e.g. there is a payload to all known PDF files appended with a payload that targets the clients' OS.

The announcement related APIs are fairly easy to implement, but I wouldn't bet on it being implemented in a fuzzed testing environment. Transmission, for example, had multiple vulnerabilities over the years. Not sure about the other client implementations.

replies(1): >>44306441 #
2. Sophira ◴[] No.44306441[source]
Don't torrents have a checksum hash, though? Or is it one of the broken hashing algorithms like MD5?
replies(1): >>44306475 #
3. cookiengineer ◴[] No.44306475[source]
That's correct. Most clients revalidate stuff after the download has been completed. Depending on how well they can redownload chunks (e.g. web seeds sometimes don't allow that if the web server does not support 206 Partial Content headers) you might have to redownload the file completely afterwards.

I had different experiences with different clients, so I guess it's work in progress on what a client does when the cache was poisoned.

Hashing algos are mostly SHA based ones that are used. No idea if someone managed to inject stuff and found collisions for SHA1 yet though. I know that there has been PoCs in the past for hash collisions of PDF files.

Context: [1] https://shattered.io/