Simplified security advisory text, fixed a typo, and updated 2.6.3
authorWayne Davison <wayned@samba.org>
Fri, 13 Aug 2004 18:46:22 +0000 (18:46 +0000)
committerWayne Davison <wayned@samba.org>
Fri, 13 Aug 2004 18:46:22 +0000 (18:46 +0000)
status in the advisory.

index.html

index f55993a47489cf2a940fbc3c0e145f80cdb79d18..81ebf307b8e34004c53f8cedbe20507bfb15dd6e 100644 (file)
@@ -13,7 +13,7 @@ available under the <A HREF="GPL.html">GNU General Public
 License version 2</A>
 
 <p><b style="color:red">**</b>
-<b>For all released veersions of rsync, see the
+<b>For all versions of rsync prior to 2.6.3pre1, see the
 <a href="security_aug04" style="color:red">August 2004 security advisory</a>!</b>
 <b style="color:red">**</b>
 <b>If you're using a version prior to 2.6.1, see the
@@ -51,24 +51,8 @@ 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).
-
-<h4>POTENTIAL EXPLOITS</h4>
-
-<p>I can think of two ways to exploit this sanitizing bug:
-
-<p>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).
-
-<p>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).
+slash(es) that the first call left behind).  It does affect certain
+option paths that cause auxilliary files to be read or written.
 
 <h4>FIXES</h4>
 
@@ -90,31 +74,11 @@ function in util.c:
 </pre>
 
 <p>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).
+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.
 
-<p>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:
-
-    <blockquote>refuse options = files-from backup-dir</blockquote>
-
-<p>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.
-
-
-<h4>EXPERIENCING DEJA VU?</h4>
-
-<p>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 (though it required a customized rsync client to do it).  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.)
 
 <h3>Rsync 2.6.2 released</h3>