Local file overwriting due to directory traversal

[Dan Rosenberg]

Binary package hint: transmission

I've discovered a design flaw in the Transmission BitTorrent client that I would consider to be a security vulnerability. The Transmission client permits arbitrary characters in the names of files included in torrents, including characters that allow directory traversal (such as "../"). In addition, the client does not prompt the user before overwriting existing files with the same name as a file that is to be downloaded via torrent.

An attacker can create a malicious torrent file containing a file named specifically to overwrite important files on disk. For example, "../.ssh/authorized_keys" could be provided as a filename included in a torrent, and Transmission will download the provided file and store it at that location (assuming the default download location of ~/Desktop), overwriting the preexisting keys file and potentially giving an attacker SSH access to the victim's machine. If the user happens to be running Transmission as root (who knows?), the possibilities are even scarier.

I have confirmed this behavior with a simple proof-of-concept torrent and text file, which I've attached. To confirm behavior, download the EVIL text file (which is just a sentence of text), and open the attached .torrent file in a child directory. For example, if EVIL is in "~/", open the .torrent from "~/Desktop". The torrent should begin seeding. From another machine, create a blank file (or any file, really) called EVIL at some location. This file represents an existing file on disk, and presumably wouldn't be called "EVIL" in a real situation. Note its contents, and open the .torrent file at a child directory, just as before. Once the download starts, you should note that the EVIL file in the parent directory has been overwritten with the contents of the torrent's EVIL file.

Clearly, the desired behavior is to download files into the current directory, not permitting any directory traversal, and perhaps prompting the user before overwriting existing data. This could be easily fixed by stripping ".." from incoming file names.

Although this attack requires a victim to open a malicious torrent file, because it does not require the victim to actually execute malicious code I would still consider it a security problem. Torrents are very widespread, and it would be trivial to host a malicious torrent containing legitimate files alongside files designed to compromise a victim's system. The fact that an attacker would have immediate knowledge of compromised victims via the torrent is especially dangerous.

I confirmed this behavior in Transmission 1.75 on Karmic, using both the GTK interface and transmission-cli.

[Charles Kerr (charlesk)]

Dan, thanks very much for the sample .torrent file. I'm travelling over Christmas at the moment but will test out the evil torrent ASAP and if it works as advertised I'll try to get a patch done in the next day or two and upload it when I get online next.

[Charles Kerr (charlesk)]

Actually it didn't take very long to test, verify, fix, and reverify, so I've committed a fix to svn.

1.7x branch: http://trac.transmissionbt.com/changeset/9829/

trunk (for 1.80): http://trac.transmissionbt.com/changeset/9830/

[Dan Rosenberg (dan-j-rosenberg)]

Great, Charles, thanks for the fast work. Looks like a good fix to me. I guess all that's left now is in the hands of the Ubuntu security folks...assigning a CVE, coordinating with other distros, and publishing an advisory.

Thanks again for the prompt response, and happy holidays.

[Charles Kerr (charlesk)]

Dan, would it be possible to keep quiet on this one for about a week s.t. I can get a 1.77 release out *before* the security announcement, so that the other distros will have a clear upgrade path?

[Dan Rosenberg (dan-j-rosenberg)]

Absolutely. I was counting on Ubuntu Security to coordinate with other distros and publish the advisory, so I would only publish myself if there's no response from them. In either event, I'm happy to wait as long as necessary to make sure the fix is available to everyone.

[Marc Deslauriers (mdeslaur)]

Charles, since your commit is public, you can release 1.77 at any time. Once you do, let me know, and I'll post a CVE request to the oss-security list.

[Charles Kerr (charlesk)]

Transmission 1.77 has been released.

The tarball is available at http://mirrors.m0k.org/transmission/files/transmission-1.77.tar.xz

Release notes are at http://trac.transmissionbt.com/wiki/Changes#version-1.77

As with 1.76, this release's diffs are extremely small to make it easier for stable distros to use.

[Charles Kerr (charlesk)]

Debian has now updated to 1.77:

http://<email address hidden>/msg264483.html

[Jamie Strandboge (jdstrand)]

Charles, is this the final commit to fix this issue:
http://trac.transmissionbt.com/changeset/9829/

[Charles Kerr (charlesk)]

Jamie: yes, that's correct.

[Jamie Strandboge (jdstrand)]

CVE requested and vendors contacted: http://www.openwall.com/lists/oss-security/2010/01/06/2

[Jamie Strandboge (jdstrand)]

Initial testing shows that Hardy and Intrepid aren't affected. Transmission strips out the '/' in '../' for a file, and therefore the file that is created using the above is $HOME/Desktop/..EVIL.

[Jamie Strandboge (jdstrand)]

Well, they aren't at least affected in the same way. Charles, would it be possible for you to confirm for Transmission 1.06 (hardy) and 1.34 (intrepid).

[Jamie Strandboge (jdstrand)]

Intrepid confirmed when using a directory. Eg, if the torrent has:
../bad
../bad/foo

Then do on the affected client:
$ mkdir bad
$ echo "my data" > ./bad/foo

Then opening $HOME/Desktop/bad.torrent will overwrite 'foo'. This doesn't seem to be a problem for Hardy, but I'm still investigating.

[Jamie Strandboge (jdstrand)]

Hardy - Karmic are now building in the security PPA. I had to rewrite the patch each of Hardy and Intrepid. Lucid will be uploaded after Alpha 2 freeze.

[Charles Kerr (charlesk)]

Nice work Jamie!

[Jamie Strandboge (jdstrand)]

http://www.ubuntu.com/usn/USN-885-1

[Marian Sigler (maix42)]

Will there also be a fix for hardy's backports package? According to the CVE's description it is also affected.

[Launchpad Janitor (janitor)]

This bug was fixed in the package transmission - 1.80~b1-0ubuntu2

---------------
transmission (1.80~b1-0ubuntu2) lucid; urgency=low

  * SECURITY UPDATE: fix arbitrary file overwrite via crafted torrent file
    - debian/patches/CVE-2010-0012.patch: adjust metainfo.c to check for '../'
    - CVE-2010-0012
    - LP: #500625
 -- Jamie Strandboge <email address hidden> Thu, 07 Jan 2010 10:50:13 -0600

[Jamie Strandboge (jdstrand)]

Marian, -backports are not officially supported and an update will not be provided by the ubuntu-security team. I suggest you file a bug requesting that ubuntu-backporters provide a backport.

[Marian Sigler (maix42)]

FTR: https://bugs.launchpad.net/hardy-backports/+bug/508178

(Jamie, I searched for a way to mark the bug as "also affects backports" and didn't find one, so I just mentioned it here.)

[Chris Coulson (chrisccoulson)]

Marian - for future reference, you click on "Also affects project", and choose a difference project if the correct one is not selected by default. Hardy backports are provided by the "hardy-backports" project. I added a backports task to this bug for you, but like Jamie said, these are not officially supported by the ubuntu-security team so it will depend on a community member who's interested in fixing it to take a look.

[Marian Sigler (maix42)]

Thanks, Chris, I'll do it correctly next time :-D That issue with the official (not) support I know of – I don't speak C unfortunately, so I won't try to copy the diff to that backports package or something ;)