[BackupPC-users] Softlink vulnerabilities in tar and rsync

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

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/