rsync - Feb 2008 - Another security advisory for a writable chroot daemon

It was recently brought to my attention that a writable rsync daemon
that has "use chroot" enabled could potentially be tricked into
loading
a user-supplied library file if the library can be uploaded into a spot
where a normal rsync action (such as an attempt to lookup a username
from an ID) would cause the loader to load it in.

If you haven't already taken steps to exclude library areas from your
writable chroot module, then you should read on.  If anyone is running
their writable module with a uid of 0 and allowing access by users that
they don't fully trust, I'd suggest fixing that first.

One easy way to keep users from uploading libraries into sensitive areas
of your chroot hierarchy is to create some directories in the top of the
chroot area without write permissions for the module's user.  Then,
exclude those directories via the daemon config file, like this:

    exclude = /etc /lib /usr

There is also a patch available that solves the problem for the case of
user/group-name lookups:

I have added of a new daemon config parameter, "numeric ids", that
disables ID lookups when enabled.  It is enabled by default for a chroot
module.  This change was just added to the 3.0.0 code for inclusion in
its upcoming release.  There is also a patch available for 2.6.9:

    http://rsync.samba.org/ftp/rsync/daemon-ids-2.6.9.diff

This patch assumes that you've already applied the munge-symlinks diff
that was mentioned in an earlier advisory.  (If you did not wish to do
that, there will be a few failed hunks that can be manually applied.)

If anyone discovers any other libraries that rsync might try to
dynamically load after it does a chroot, please let me know.

..wayne..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.samba.org/archive/rsync/attachments/20080215/62b951ff/attachment.bin