mailing list archives
Re: Symlinks and filesystem recursion vulnerabilities: Action needed or ignore?
From: Solar Designer <solar () openwall com>
Date: Wed, 27 Jul 2011 03:22:36 +0400
I'm sorry I'm late to comment on this. Since it's been a while, I'll
include the entire message by halfdog below (it's too long to top-quote).
My opinion is that we have a real issue here, and it's been patched in
GNU tar 1.24+ (Paul Eggert did all the hard work - thanks!)
In his writeup, halfdog has included copies of two lengthy e-mails by me
from our discussion of the issue in 2010 (with GNU tar developers and
CERT CC'ed). I recommend reading those:
Now that we have a fix in GNU tar, the question is whether any other
tools need fixing as well, and which ones. I am not sure. We could as
well declare that GNU tar 1.24+ is the only tool intended to perform
backups with. ;-) Really, what alternatives are there? Some
proprietary backup tools (that traverse directories on their own rather
than invoke tar)? Of free software, rsync and cpio come to mind, but I
wouldn't call these backup tools. Of these, I expect that rsync has
lots of other security risks if used on untrusted directory trees, and
cpio's functionality is not any better than tar's (for backups).
I understand that a lot of people do (mis)use rsync on untrusted trees,
though, so someone might want to review it, enumerate the security
problems, and then decide what to do about them. Meanwhile, to me rsync
is just not meant to be used on untrusted directory trees.
On Thu, May 05, 2011 at 12:21:55AM +0000, halfdog wrote:
I have some problems to decide, what to do about a class of
vulnerabilities I discovered over a year ago. It seems that quite a few
backup applications are (or were) vulnerable to special symlink attacks,
when they are run as root and crawl though directory structures under
control of a malicious user. The key idea is to create a file in the
user writable location, e.g. /home/user/etc/shadow, which is just a
normal user owned file. When the root-run backup process has read the
directory /home/user/etc but before opening shadow, /home/user/etc is
symlinked to /etc. Backup program might then read /etc/shadow, which is
included in user dump as /home/user/etc/shadow. Malicious user could
then trigger restore, e.g. via social engineering/restore-my-site button
at hosters/deleting other files and claim loss. Apart from file
inclusion, this method can also be used to create arbitrary large backups.
Issue https://bugs.launchpad.net/bugs/570050 contains one POC, that
allows to include arbitrary files (e.g. /etc/shadow) in a tar backup of
/home/user, this was fixed last year at least in version 1.25 (No
advisory or CVE so far). Solaris POC can be found in references section
. Please mind, that new tar versions are already fixed.
The issue can also triggered remotely, e.g. via nfs, but since inotify
does not work, one has to win the symlink race just with luck. It also
allows to read files outside a container-virtualization guest, e.g.
vserver, if backup runs outside of virtualization.
I have tested some backup tools on ubuntu linux and solaris, before tar
was fixed, all of them were vulnerable to this kind of attack. From my
point of view, poor syscall interface makes it harder to write secure
recursion code, since one would always have to keep the parent directory
open and use openat calls to traverse the tree. This causes code to
become more complex and might increase the risk or resource starvation,
e.g. exceeding of maximal open file descriptors since each directory has
to be kept open. I sent a mail to linux kernel mailing list, asking for
opinions on modification/addition of more secure syscalls (see
http://lkml.org/lkml/2011/4/19/43) but received no replies.
The tar backup restore issue https://bugs.launchpad.net/bugs/570050 also
contains another POC (create backdoored ls), that does not expose a real
bug in the tar backup software but bad administrator practice: per
design, there is no backup program that could securely restore files
directly to a running system. Due to that reason, any restore might lead
to root privilege escalation. It seems, that this is not widely known
and to my knowledge, there are no backup best practice guidelines
addressing this issue. If I remember correctly, some backup tools tested
(was it backuppc?) allow remote restore to live systems without warning
the user about the dangers of this action.
Evaluation: Should there any actions be taken to check and secure file
system recursion programs as such? Or is the issue too low risk, so that
simple ignoring it is better? Exploitation already requires that
attacker is able to create files, links, so an attacker might find much
easier ways to gain further access than this method. When ignoring these
issues, human opensource resources could be used to address more
pressing security challenges.
What do you think?
PS: A short writeup of this issue can be found at
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
- Re: Symlinks and filesystem recursion vulnerabilities: Action needed or ignore? Solar Designer (Jul 26)