[Box Backup] OT?: Softlink vulnerabilities in tar and rsync

Achim J. Latz achim+box at qustodium.net
Mon May 30 14:04:26 BST 2011


Hello list, this might be slightly OT

I know that Box Backup is not using rsync per se, but could some of the 
experts please evaluate how the recent vulnerabilities in tar and rsync 
(see below) could affect BB's modified algorithm?

Best regards, Achim

-------- Original Message --------
Subject: [BackupPC-devel] Softlink vulnerabilities in tar and rsync
Date: Sun, 29 May 2011 16:41:35 -0700
From: Craig Barratt <cbarratt at users.sourceforge.net>
Reply-To: Developers discussion <backuppc-devel at lists.sourceforge.net>
To: <backuppc-users at lists.sourceforge.net>, 
<backuppc-devel at lists.sourceforge.net>, 
<backuppc-announce at lists.sourceforge.net>

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



More information about the Boxbackup mailing list