[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110726232236.GA28058@openwall.com>
Date: Wed, 27 Jul 2011 03:22:36 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Symlinks and filesystem recursion vulnerabilities: Action needed or ignore?
Hi,
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:
http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks/
http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks/20100827-SolarDesignerAnalyzingTarSecurityIssue.eml
http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks/20100828-SolarDesignerOnBackupAndSymlinks.eml
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.
Alexander
On Thu, May 05, 2011 at 12:21:55AM +0000, halfdog wrote:
> Hello List,
>
> 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
> at http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks/
> . 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
> http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks/
>
> - --
> http://www.halfdog.net/
> PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
