copy & paste of the advisory: August 2004 Security Advisory August 12th, 2004 Background 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). It does affect certain option paths that cause auxilliary files to be read or written. The Fix 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 (it is currently in release-testing). One potential fix that doesn't require recompiling rsync is to set "use chroot = true" for all the modules in the rsyncd.conf file. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Jon or Mike will work at this?
2.6.0-r3 and 2.6.2-r4 have the updated patch and are now in portage
Arches please mark net-misc/rsync-2.6.0-r3 stable
tested on x86 ppc sparc arm hppa amd64 ia64 and marked stable
marked stable on ppc64, thanks!
marked stable on mips
Stable on alpha.
OK, so if you somehow pass something that looks like "foo/..//bar" to sanitize_path, you will get "/foo/bar" back, which is bad because of the leading slash. I looked at this with an eye towards the Impact section of the GLSA, and here's where I see this being a problem (all line numbers are from rsync 2.6.0): - The files_from option on the server itself (options.c:677) - Symlinks. There's a usage of sanitize_path on external data without clean_fname first. I could be wrong about this one, though ... I haven't had a chance to follow that data structure through. (flist.c:580) - Files that are listed in the files_from file itself. (flist.c:946) - Possibly other command-line arguments (see clientserver.c:431) although I suspect those are sanitized later (again, I haven't had time to check). In all (potential) cases, the patch looks good. Please keep in mind I'm not that familiar with the rsync source myself, so I could be wrong on some of these. I would appreciate it if the reporter--or someone else familiar with rsync--could take a look at these and let us know which are actually valid so we can include that information in the GLSA.
The original reporter just picked up the advisory and doesn't have a clue about the rsync source code - sorry ;-)
GLSA 200408-17 s390 please remember to mark stable to benifit from GLSA.