From: Craig B. <cba...@us...> - 2011-05-29 23:41:55
|
Over the last year there has been some interesting work in discovering softlink vulnerabilities that affect tar and rsync. The implication for BackupPC is significant - these vulnerabilities are exposed in the typical manner that BackupPC uses tar and rsync - in particular, due to the elevated privileges used to run tar and rsync on the client. This email summarizes the issue and what steps can be taken to minimize the exposure. The issue is actually quite a fundamental one that results from how many utilities traverse a file system. Typically each directory is opened and read, and then for each entry in that directory the file is processed or sub-directories are recursed. If a softlink is encountered, the link contents is read by tar and rsync, but by default not followed. However, there is a race condition between the reading of the directory and subsequent processing of the files in that directory. The reason is that each file is referred to by name, typically by concatenating the directory path with the file. However, if a higher level directory is replaced by a symbolic link after the directory read, but before each directory entry is read, files elsewhere across the file system will be read instead. If tar or rsync are running as root, then important system files can be incorrectly read and backed up by tar or rsync. Since BackupPC doesn't enforce client user permissions when browsing a backup, any authorized user can read any of the backup files, including ones that should only be visible with elevated privileges. There are similar issues on the write (ie: restore) side of things. If a directory is replaced by a symbolic link as tar or rsync write to files below that directory, then arbitrary files elsewhere in the file system can be overwritten during restore. An overview of the issue and examples of exploiting these vulnerabilities are here: http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks If you look at recent tar documentation in section 10 you will see a discussion of these kinds of issues: http://www.gnu.org/software/tar/manual/html_node/Reliability-and-security.html#SEC168 In general there are various vulnerabilities that can occur when a live file system is being read or written by utilities like tar and rsync, especially when they are running as root. This issue certainly affects BackupPC, since most commonly tar and rsync are run as root on the client. I do not know if these issues also occur on WinXX using rsync/cygwin, but it is likely they do. What steps should you take to minimize the impact of this issue? First, tar has been fixed as of 1.24 to avoid several of the race conditions on read. The fixes involved using alternate OS calls for reading/writing directories or files that unambiguously refer to the directory in which they reside (rather than referring to them traditionally via paths). It's not clear whether rsync will adopt this same fix. However, on write (restore), you cannot avoid the basic issue of the underlying filesystem changing in a devious manner. Here are some suggested remedies. For backups, you need to be aware that the read vulnerability can be used to allow protected files to be included in a backup in parts of the tree that would typically not include those files. You can avoid this read vulnerability by: - If you can backup from a snapshot then there are no read race conditions since the snapshot is frozen. - If you are using the tar xfer method, upgrade to tar 1.24+ on your linux/unix clients. - Don't run tar or rsync as root when you are backing up any directories that untrusted users can write to. An untrusted user could use the read vulnerability to backup and then view privileged files (ie: files that can only be read by root). If you can't do any of those: - If it's not possible or convenient to run tar or rsync as a regular user, then make sure any untrusted users cannot view or restore the backups. - If an untrusted user asks you to restore a backup, you *should* run the restore as root, so that any illegitimate files will be restored with their correct permissions, and therefore not be available to the untrusted user to read after restore. But you must restore to a new, protected, location and then rename the top-level directory to its correct location. For restores: - Disable direct restore by untrusted users on your linux/unix clients, unless you configure it to run as a regular user. This removes the ability for them to exploit the write vulnerability during restore. - When you restore, always restore to a new, protected directory, and after the restore is done, move/rename the directory to the restore location. Otherwise, an untrusted user can ask you to start a restore and if it is done in place then they can exploit the write vulnerability. If you manually run a command like cp -a restoreDir/* origDir as root, this will also expose you to some of the write vulnerabilities. Craig |