Hacker News Reader

Comment by nneonneo | Hacker News Reader

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.

View on HN

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

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.

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?

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.

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.

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

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/

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

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

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)

Reply on news.ycombinator.com