Resurrecting a dead torrent tracker and finding 3M peers

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.

I've written hobby-quality clients and I think the answer is yes. First, you're dealing with input from a server you don't control, and second, you're doing quite a bit of interaction with the filesystem. It's hard enough to write a functional client in a memory safe language, getting it correct in C or C++ is bound to be pretty tough.

That's what I was hoping the author would explore.

Most torrent clients that people use (though not all) are actually wrappers around libtorrent, which is very well tested and has even been audited.

Think about how many other programs are written in not-rust. You're worrying over nothing (or, alternatively, you should be worried about just about everything)

Transmission had a remote code execution vulnerability (CVE-2018-5702) through DNS rebinding that allowed attackers to execute arbitrary commands - tracker exploitation is definitely a real attack vector.

Possible but unlikely. The protocol is relatively simple, and what clients are out there have already been subjected to tons of untrusted input.

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.

Don't torrents have a checksum hash, though? Or is it one of the broken hashing algorithms like MD5?

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/

Libtorrent even has fuzzers specifically for communications with trackers and DHT peers. Obviously this isn’t perfect but it gives me much more confidence than other implementations do.

Using a container sandbox such as gvisor would definitely help. Or even using firejail for normal systemd processes

It's worth noting that there are at least 3 variants calling themselves "libtorrent" and to my knowledge they don't have a lot in common implementation wise.

1. libtorrent-rasterbar — https://packages.debian.org/sid/libtorrent-rasterbar-dev

2. libtorrent-rakshasa (rTorrent) — https://packages.debian.org/sid/libtorrent-dev

What’s the third one?