TUCoPS :: Unix :: General
:: rsync-1.htm
rsync can, under weird conditions, inadvertently transfer permissions inappropriately
Vulnerability
rsync
Affected
Systems running rsync
Description
Tridge found following. He discovered a security hole in rsync.
The problem happened when all of these conditions held true:
1) the source file list contains exactly one filename and that
is the name of an empty directory
2) the source directory name is specified on the command line
as "somedir/" or "somedir/." or "." not as "somedir"
3) the destination directory doesn't exist
4) you have recursion and permission transfer enabled (the -a
option will do this)
5) the working directory of the receiving process is not the
destination directory (this happens when you do remote
rsync transfers)
(the short summary is that you need to be transferring an empty
directory into a non-existent directory)
In that case (which is quite rare) the permissions from the empty
directory in the source file list were set on the working
directory of the receiving process. In the case of a remote rsync
over rsh or ssh this means that the permissions on your home
directory are changed to those of the empty directory you are
transferring. This is a serious bug (and security hole) as it
may change your home directory permissions to allow other users
access to your files. A user can't exploit this hole deliberately
to gain privileges (ie. this is not an "active" security hole) but
a system administrator could easily be caught by the bug and
inadvertently compromise the security of their system. This bug
has been present in all versions of rsync.
Solution
Released version rsync 2.3.1 fix it. The new version and patches
against the last version are available at
http://rsync.samba.org/
ftp://rsync.samba.org/pub/rsync/
To see if you have been hit by this bug you should look at the
permissions on your home directory. If they are not what you
expect then perhaps you have been bitten by this bug. The fix is
to chmod your home directory back to the correct permissions and
upgrade to rsync 2.3.1. The bug is in the receiving side of
rsync, so it is quite safe to continue to use older anonymous
rsync servers as long as you upgrade your client.
Debian GNU/Linux 2.1 alias slink:
ftp://ftp.debian.org/debian/dists/proposed-updates/rsync_2.3.1-0.slink.1.diff.gz
ftp://ftp.debian.org/debian/dists/proposed-updates/rsync_2.3.1-0.slink.1.dsc
ftp://ftp.debian.org/debian/dists/proposed-updates/rsync_2.3.1.orig.tar.gz
ftp://ftp.debian.org/debian/dists/proposed-updates/rsync_2.3.1-0.slink.1_alpha.deb
ftp://ftp.debian.org/debian/dists/proposed-updates/rsync_2.3.1-0.slink.1_i386.deb
ftp://ftp.debian.org/debian/dists/proposed-updates/rsync_2.3.1-0.slink.1_m68k.deb
ftp://ftp.debian.org/debian/dists/proposed-updates/rsync_2.3.1-0.slink.1_sparc.deb
Debian GNU/Linux unstable alias potato:
ftp://ftp.debian.org/debian/dists/unstable/main/source/net/rsync_2.3.1-2.diff.gz
ftp://ftp.debian.org/debian/dists/unstable/main/source/net/rsync_2.3.1-2.dsc
ftp://ftp.debian.org/debian/dists/unstable/main/source/net/rsync_2.3.1.orig.tar.gz
ftp://ftp.debian.org/debian/dists/unstable/main/binary-alpha/net/rsync_2.3.1-2.deb
ftp://ftp.debian.org/debian/dists/unstable/main/binary-arm/net/rsync_2.3.1-2.deb
ftp://ftp.debian.org/debian/dists/unstable/main/binary-i386/net/rsync_2.3.1-2.deb
ftp://ftp.debian.org/debian/dists/unstable/main/binary-m68k/net/rsync_2.3.1-2.deb
ftp://ftp.debian.org/debian/dists/unstable/main/binary-powerpc/net/rsync_2.3.1-2.deb
ftp://ftp.debian.org/debian/dists/unstable/main/binary-sparc/net/rsync_2.3.1-2.deb