[rsync-announce] security hole in non-chroot rsync daemon

--===============1614871705==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline


--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

SUMMARY

There is a path-sanitizing bug that affects daemon mode in all recent
rsync versions (including 2.6.2) but only if chroot is disabled. It
does NOT affect the normal send/receive filenames that specify what
files should be transferred (this is because these names happen to get
sanitized twice, and thus the second call removes any lingering leading
slash(es) that the first call left behind).

POTENTIAL EXPLOITS

I can think of two ways to exploit this sanitizing bug:

For anyone running an rsync daemon with chroot turned off while allowing
the uploading of files, this bug can allow a carefully crafted filename
for the --backup-dir option to cause rsync to overwrite a file outside
of the module's path (if the UID of the daemon module has adequate
permissions, of course).

For anyone running a 2.6.0 or 2.6.1 rsync daemon with chroot turned off,
this bug can potentially reveal the contents of a file outside the
module's hierarchy if the user uses a carefully crafted --files-from
filename. This causes each line of the file to be revealed to the user
as link_stat errors (other rsync versions hide these errors from the
remote user).

FIXES

The best fix is to apply this one-word patch to the sanitize_path()
function in util.c:

--- orig/util.c 2004-04-27 12:59:37 -0700
+++ util.c 2004-08-11 23:37:27 -0700
@@ -743,7 +743,7 @@
allowdotdot = 1;
} else {
p += 2;
- if (*p == '/')
+ while (*p == '/')
p++;
if (sanp != start) {
/* back up sanp one level */

This bug is fixed in the CVS version of rsync, and will be released in
version 2.6.3 (which will begin release-testing soon).

One potential fix that doesn't require recompiling rsync is to set
"use chroot = true" for all the modules in the rsyncd.conf file.

A band-aid work-around for those running a 2.6.2 daemon is to exclude
the use of the above options in the rsyncd.conf file:

refuse options = files-from backup-dir

Note, however, that this "refuse options" configure item was broken in
older rsync versions, such as all the 2.5.x versions and 2.6.0.

EXPERIENCING DEJA VU?

Yes this bug is similar to the last security problem fixed in rsync in
that the effect is the same even though the cause is slightly different.
In the older bug, there was a way to slip certain option values through
the option-parsing without sanitize_path() getting called on the path at
all. In this new bug, the problem is that a carefully crafted path can
be cleaned improperly, resulting in an absolute filename being generated
instead of a relative one. (I note that this cleaning problem in the
sanitize_path() function exists even as far back as rsync 2.3.0.)

...wayne..

--wac7ysb48OaltWcw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBGy5YbIWfsUuWqMURAgikAJ0Q4JUDeOEZlIBf/73oeJ19nDFPJgCgwBb2
h2cCYBP1p7p995R1PobQhxc=
=zk3D
-----END PGP SIGNATURE-----

--wac7ysb48OaltWcw--

--===============1614871705==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
rsync-announce mailing list
rsync-announce@lists.samba.org
http://lists.samba.org/mailman/listinfo/rsync-announce

--===============1614871705==--