Subject: Re: tar security issue VU#278501
From: Solar Designer
To: halfdog
Cc: "Dmitry V. Levin" Sergey Poznyakoff, eggert cert-at-cert.org
Date: Sat, 28 Aug 2010 02:27:02 +0400

Hi all,

Roman - thank you for getting us all (everyone who cares?!) onto the
same discussion thread, finally.

On Fri, Aug 27, 2010 at 09:02:18AM +0000, halfdog wrote:
> * Do you think, that this security issue would need a fix now?

There are at least two security issues:

1. GNU tar vulnerability seen on the "read example".  This is a
full-blown vulnerability in the GNU tar program, and it needs to be
fixed in the code as such (even though it's not trivial to fix).
The fact that many other programs are also affected is a poor excuse.
There are also programs that are not affected - e.g., the fts(3) code in
glibc and the *BSD mtree(8) program are not affected.

The "read example", or rather its variation that was provided to us by
CERT in a follow-up message, relies on reasonable expectations of the
sysadmin running tar only.  It does not rely on any undocumented
behavior or unreasonable expectation.  So the vulnerability is solely in
the tar program.

2. "Write example", which relies on being able to modify the tree that a
tarball is being extracted into.  This relies on an unreasonable
expectation by the sysadmin (or by a web-based admin control panel), so
it is not a GNU tar issue.  Besides, making tar safe for extracting over
untrusted directory trees is too difficult or even impossible.  The
specific attack that was mentioned is not the only one.  I think tar
would happily write a regular file over a (sym)link (that is, where the
last path component is a link to something else), so an attack would not
require playing with path components higher in the path.  I expect this
kind of behavior from tar and from almost all other tools that write
into files.

> My point of view: Both POCs (read/write) rely on bad backup handling practices
> so a "secure backup handling practices" document for admins could help reducing
> the impact to a mere annoyance (e.g. inevitable DOS of backup systems) but no
> compromise.

Do you have a specific suggestion on how live systems may be backed up
with tar without being exposed to your "read example" security risk?
I am not aware of ways to achieve that, other than by fixing tar itself.
I am aware of some partial mitigations only, and they have their own
drawbacks while not fully solving the problem.

So, no, GNU tar must be patched.  As to a specific approach to use, this
needs discussion.  One approach may be to have tar's directory traversal
be similar to fts(3), where it'd fchdir() into each directory.  For
actually reading files, it can use a combination of O_NOFOLLOW (where
available) and fstat() checks - this will take care of possible attacks
via the last path component.  This is what we do in mtree(8).

> The modification of tar would need a specification of tar behavior in
> environments with concurrent modifications. Since there is no such specification
> after 30? years of use, it is highly unlikely to get it in near future.

I agree that such a specification for GNU tar would be nice to have.
Right now, it is implied.  Specifically, it is implied that tar should
be safe for backing up live systems - in the sense that any attack on
its directory traversal should be limited to a DoS.

There are _lots_ of systems that depend on this implied property.
Almost all current uses of tar for making backups are affected.

> Providers with "restore my site" might use a workaround with chroot+tar,

chroot to where?  User home directory?  That would be a new security
hole (chroot into a user-writable directory is a local-root hole).

> su+tar

Sure, but only for sub-trees containing files of a single owner.
Quite often the task is different.

> or tar to hidden location and move of data to target directory.

That's the right way to partially restore a live system from a backup
dump.  That's what we normally do.  Not a workaround, but just the way
to do it.

Anyhow, the only problem in tar is with reads (making backups), not
writes (restoring from backups).  So let's focus on fixing the tar
problem first.

> * Do you think, that at the moment releasing an advisory about bad backup/file
> handling practices would be sufficient?

No.  tar needs to be patched.  It is OK to do that when the issue is
already fully public if we're unable to come up with a fix sooner...

> I think, that the issue is too low-priority to acquire enough human resources
> sufficient for in-depth analysis (is it OS/libc/tar or bad practice) and real
> fix in the current closed community (only small group informed). On the other
> hand, public discussion could help finding simple/optimal solution. And perhaps
> there is a group of people out there that would like to take over analysis and
> fixing. Therefore I would suggest disclosure.

I don't mind.  It is quite obvious to me where the issues are, though.

Maybe the public discussion will help in coming up with a "proper" fix
for tar.  I've only suggested one specific approach (cd'ing into each
directory), which has its drawbacks (it is sometimes risky to have an
untrusted current directory - e.g., in case of coredumps).  It'd be nice
to have people suggest other approaches and to pick "the best" one after
some discussion.

On systems with openat(2), it could be used to avoid changing the
current directory.  This would avoid the security risk I've just mentioned.

> * Has someone performed a risk analysis of the issue? Do you think, that this
> issue would really be exploited somewhere/somehow?

This is tricky.  I am aware of plenty of attacks that are somehow not
actually being performed - e.g., if a sysadmin goes into a user's home
directory and issues "vi somefile" as root, the user could have used
this opportunity to overwrite any file on the system.  However, I am
unaware of this kind of attack having been performed in the wild...
which doesn't mean that it was never done, though.  Yet I avoid things
like that on systems I co-administer, and I ask others to be careful in
this respect.  Thus, I am uncomfortable about having the vulnerability
in tar and just sitting on it.  We need to fix the code, really.

Thanks again,

Alexander