rsync versions 2.6.2 and below have a flaw that allows malicious users to read or write arbitrary files on a vulnerable system. In order to exploit this vulnerability, the rsync daemon cannot be running in a chroot.
c1db552a349b4582ecc14879891615a1226530a7b6645bcf16da893b2cb72992<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>rsync</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff" TEXT="#000000" VLINK="#292555" LINK="#292555" ALINK="#cc0033">
<h3>Rsync 2.6.3pre1 released</h3>
<h3 style="color:red">August 2004 Security Advisory</h3>
<p><i style="color:#777777">August 12th, 2004</i>
<h4>Background</h4>
<p>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.
<h4>The Fix</h4>
<p>The best fix is to apply this one-word patch to the sanitize_path()
function in util.c:
<pre>
--- 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 */
</pre>
<p>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).
<p>One potential fix that doesn't require recompiling rsync is to set
"use chroot = true" for all the modules in the rsyncd.conf file.
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed