chapter 6, installing kernel headers

Richard Lightman richard at
Wed Jan 29 05:31:32 PST 2003

* Gerard Beekmans <gerard at> [2003-01-29 13:00]:
> On January 19, 2003 12:24 pm, Don Smith wrote:
> > His example is off. I think he is saying someone could append a
> > trojanned /bin/ls to any tarball and if you extract that tarball as
> > root, the trojanned ls would end up in your /bin. Probably a good idea
> > to not extract things as root.
No. The example works as given, with the malliciously contructed tar
archive that I provided. That archive required a little trickery to
create, but it is not beyond the skill of someone capable of putting
a trojanned archive on a popular ftp site.

> Normally tar won't do that, unless you unpack the tarball with the -P option 
> which will not strip a leading / from the paths.
> As long as you don't add -P to your untar command, those things won't happen.
That is not it at all. Even without the -P, a maliciously constructed
tar archive can put files in ANY directory writable by the user running
tar. It does not matter what the current directory is either.

The magic trick is to create an archive with a link to

Then create a copy of the contents if the archive with the link
replaced by a directory. In that directory, you place your trojan that
you want to end up in /target/. Finally you append trojan to the

Tar does not spot that you are creating a mallicious archive, and even
if later versions do spot it, I can still use the current stable
version to create mallicious archives.

Tar does some checking to prevent writing outside the current
directory when extracting, but these checks are currently defective.
There is no reason for tar not to create the symlink. I do not know
the posix definition of tar, but I would be nice if tar complained
that extracting 'trojan' cannot be done because 'target' is a symlink,
not a directory.

What tar actually does is to unpack trojan in the directory that is
the target of the symbolic link.

Unpacking tar archives as root really is a security risk.


Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list