Package: tar
Version: 1.14-2
Severity: normal
Tags: security

Suppose that I have a tar file like this:

-rw-r--r--  1 joey joey 702M Jan 13 23:05 
windows-prerelease-sourcecode.microsoft.NET:2005.tgz

If a user downloads this hot commodity from me and unpacks it with tar,
they're in for a suprise, because microsoft can dertermine their username,
and the machine they're unpacking it on.

Alternatively, perhaps I'm distributing something more legitimate, such
as:

-rw-r--r--  1 joey joey 1.9M Jan 13 23:34 dpkg_v2.kitenet.net:20040113.tar.gz

I distribute it with a md5sum, which you can check before unpacking it.
Most people who unpack it will get dpkg v2 (about time, too!), but a few
people will get a completly different set of code, even though the md5sum
checked out.

I imagine that tar-heads will have figured out the problem with the above
files, but unfortunatly tarballs are not always so easy to see, sometimes
they're hidden in a completly innocuous package, such as myprogram.src.rpm.


Details: This is due to some very loose parsing of what tar considers to be
a rmt volume name. Anything with a colon will do, though a real rmt volume
probably has a path after the colon.

All microsoft needs to pull this off is a
windows-prerelease-sourcecode.microsoft.NET domain and some daemon to
listen for rsh and ssh connections and log them, and a pack of lawyers
to go after the people who thought they were pirating the code. Users
will get a funny message from tar when it fails to connect to the rmt
server as they try to unpack the file.

For my dpkg v2 exploit, I need a bit more finesse, such as a server with
modified rsh and ssh servers that let anyone in and connect them to a
custom written rmt program, which decides whether to send them the
original file, or the trojaned version.

Limitations: I haven't checked whether the .src.rpm exploit would really
work. dpkg-source does not seem to be vulnerable to this kind of
problem. Some systems will be missing a suitable rsh command.

I don't know if support for rmt could be safely dropped from tar, or turned
off by default. At a minimum, I'd like a way to turn it off to avoid this
type of attack.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature

Reply via email to