oss-sec 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
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
Current thread:
- Re: Symlinks and filesystem recursion vulnerabilities: Action needed or ignore? Solar Designer (Jul 26)