Potential Security Issue

[JamieSlome]

Hello,

We recently received a vulnerability disclosure against your repository. I have read your security policy and am opening an issue to follow your desired process.

If you would like me to e-mail over the details or put them on the GitHub Issue, I'm more than happy to facilitate this for you. Otherwise, you can access the advisory here.

It is private to you and the discloser of the report.

If you have any questions, let me know.

-- Jamie from huntr.dev

[anacrolix]

@JamieSlome I reviewed your advisory. You may disclose this vulnerability here.

[JamieSlome]

Sure, I have just hard copied the contents of the disclosure from the platform:

✍️ Description

I have confirmed SSRF vulnerability in `anacrolix/torrent.

🕵️‍♂️ Proof of Concept

1. Open a port over localhost (python3 -m http.server 5000)
2. Run this command torrent download 'magnet:?xt=urn:btih:08ada5a7a6183aae1e09d831df6748d566095a10&dn=Sintel&xs=http://localhost:5000'

Now you will see in HTTP logs that a GET request was received

💥 Impact

This could be exploited if the user copies a malicious magnet link for downloading through anacrolix/torrent or if a there is webserver that takes user magnet URL for downloading files with the use of anacrolix/torrent

References

https://github.com/assetnote/blind-ssrf-chains

https://portswigger.net/web-security/ssrf/blind

[0xrishabh]

@anacrolix Do you have any suggestion on how to mitigate this, so maybe I can go around fixing this.

[anacrolix]

I would expect a "trust" flag or something when merging torrent specs would enable things like using torrent sources. Alternatively, based on some RFC, filter access to certain IP nets/hostnames. It's a very wide area for exploitation, so it's hard to say what the right answer is.

[0xrishabh]

I think what we could do is that if the developer using the library wants to announce the URL to be localhost, he has to pass a flag called --insecure otherwise no request will be sent to private IP.

Do you think this will work?

[anacrolix]

I don't think it's sufficient. It could be possible to attack arbitrary network locations, even on the wider internet. I think that either use of the torrent sources should be be manual (i.e. caller code has to invoke it itself and assume responsibility), or a Trusted field in TorrentSpec could automatically enable features like this (and responsibility is again deferred to the package consumer).

[0xrishabh]

@anacrolix If the user itself has to pass --insecure flag isn't the user is taking responsibility?

It could be possible to attack arbitrary network locations, even on the wider internet. I don't think this is a problem if the request is getting sent to the internet as long it's not private IPs

[anacrolix]

I still think it's a grey area, but if you're looking to get started, let's go with filtering access to local subnets unless --allow-insecure or something is passed. Include a field in the torrent package somewhere, probably TorrentSpec, and a flag setting it in cmd/torrent.

You'll need to resolve URLs, then check the IP, then pass appropriate host headers, or add hooks before the dial in a http client.

[0xrishabh]

@anacrolix I have started to work on this meanwhile can you look into this https://huntr.dev/bounties/2-anacrolix/torrent/

[anacrolix]

@0xrishabh any update on this?