index.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3 <HEAD>
   4 <TITLE>rsync</TITLE>
   5 </HEAD>
   6 <!--#include virtual="header.html" -->
   7
   8 <H2 align="center">Welcome to the rsync web pages</H2>
   9
  10 rsync is an <A HREF="http://www.opensource.org/">open source</A>
  11 utility that provides fast incremental file transfer. rsync is freely
  12 available under the <A HREF="GPL.html">GNU General Public
  13 License version 2</A>
  14
  15 <p><b style="color:red">**</b>
  16 <b>For all released veersions of rsync, see the
  17 <a href="security_aug04" style="color:red">August 2004 security advisory</a>!</b>
  18 <b style="color:red">**</b>
  19 <b>If you're using a version prior to 2.6.1, see the
  20 <a href="#security_apr04" style="color:red">April 2004 security advisory</a>!</b>
  21 <b style="color:red">**</b>
  22 <b>If you're using a version prior to 2.5.7, also see the
  23 <a href="#security_dec03" style="color:red">December 2003 security advisory</a>!</b>
  24 <b style="color:red">**</b>
  25
  26 <a name="security_aug04"></a>
  27 <h3 style="color:red">August 2004 Security Advisory</h3>
  28
  29 <h4>SUMMARY</h4>
  30
  31 <p>There is a path-sanitizing bug that affects daemon mode in all recent
  32 rsync versions (including 2.6.2) but only if chroot is disabled.  It
  33 does NOT affect the normal send/receive filenames that specify what
  34 files should be transferred (this is because these names happen to get
  35 sanitized twice, and thus the second call removes any lingering leading
  36 slash(es) that the first call left behind).
  37
  38 <h4>POTENTIAL EXPLOITS</h4>
  39
  40 <p>I can think of two ways to exploit this sanitizing bug:
  41
  42 <p>For anyone running an rsync daemon with chroot turned off while allowing
  43 the uploading of files, this bug can allow a carefully crafted filename
  44 for the --backup-dir option to cause rsync to overwrite a file outside
  45 of the module's path (if the UID of the daemon module has adequate
  46 permissions, of course).
  47
  48 <p>For anyone running a 2.6.0 or 2.6.1 rsync daemon with chroot turned off,
  49 this bug can potentially reveal the contents of a file outside the
  50 module's hierarchy if the user uses a carefully crafted --files-from
  51 filename.  This causes each line of the file to be revealed to the user
  52 as link_stat errors (other rsync versions hide these errors from the
  53 remote user).
  54
  55 <h4>FIXES</h4>
  56
  57 <p>The best fix is to apply this one-word patch to the sanitize_path()
  58 function in util.c:
  59
  60 <pre>
  61 --- orig/util.c 2004-04-27 12:59:37 -0700
  62 +++ util.c      2004-08-11 23:37:27 -0700
  63 @@ -743,7 +743,7 @@
  64                                 allowdotdot = 1;
  65                         } else {
  66                                 p += 2;
  67 -                               if (*p == '/')
  68 +                               while (*p == '/')
  69                                         p++;
  70                                 if (sanp != start) {
  71                                         /* back up sanp one level */
  72 </pre>
  73
  74 <p>This bug is fixed in the CVS version of rsync, and will be released in
  75 version 2.6.3 (which will begin release-testing soon).
  76
  77 <p>One potential fix that doesn't require recompiling rsync is to set
  78 "use chroot = true" for all the modules in the rsyncd.conf file.
  79
  80 <p>A band-aid work-around for those running a 2.6.2 daemon is to exclude
  81 the use of the above options in the rsyncd.conf file:
  82
  83     <blockquote>refuse options = files-from backup-dir</blockquote>
  84
  85 <p>Note, however, that this "refuse options" configure item was broken in
  86 older rsync versions, such as all the 2.5.x versions and 2.6.0.
  87
  88
  89 <h4>EXPERIENCING DEJA VU?</h4>
  90
  91 <p>Yes this bug is similar to the last security problem fixed in rsync in
  92 that the effect is the same even though the cause is slightly different.
  93 In the older bug, there was a way to slip certain option values through
  94 the option-parsing without sanitize_path() getting called on the path at
  95 all.  In this new bug, the problem is that a carefully crafted path can
  96 be cleaned improperly, resulting in an absolute filename being generated
  97 instead of a relative one.  (I note that this cleaning problem in the
  98 sanitize_path() function exists even as far back as rsync 2.3.0.)
  99
 100 <h3>Rsync 2.6.2 released</h3>
 101
 102 <p>April 30th, 2004
 103
 104 <p>Rsync version 2.6.2 has been released.  It is a bugfix release that mainly
 105 fixes <b>a bug with the --relative option (-R) in 2.6.1</b>
 106 that could cause files to be transferred incorrectly.  This only affected a
 107 source right at the root of the filesystem, such as "/" or "/*" (using "."
 108 as the source after a chdir to "/" was not affected, however).
 109
 110 <p>See the <a href="/ftp/rsync/rsync-2.6.2-NEWS">release NEWS</a> for the
 111 details of what else was fixed.
 112
 113 <p>See the <a href="download.html">download page</a> for all the ways
 114 to grab the new version, or snag one of these: <b>
 115 <a href="/ftp/rsync/rsync-2.6.2.tar.gz">rsync-2.6.2.tar.gz</a>
 116 (<a href="/ftp/rsync/rsync-2.6.2.tar.gz.asc">signature</a>),
 117 <a href="/ftp/rsync/rsync-2.6.1-2.6.2.diffs.gz">rsync-2.6.1-2.6.2.diffs.gz</a>
 118 (<a href="/ftp/rsync/rsync-2.6.1-2.6.2.diffs.gz.asc">signature</a>)</b>.
 119
 120 <h3>Rsync 2.6.1 released</h3>
 121
 122 <p>April 26th, 2004
 123
 124 <p>Rsync version 2.6.1 has been released.  It is primarily a performance
 125 release that requires less memory to run, makes fewer write calls to the socket
 126 (lowering the system CPU time), does less string copying (lowering the user CPU
 127 time), and also reduces the amount of data that is transmitted over the wire.
 128 There have also been quite a few bug fixes.  See the
 129 <a href="/ftp/rsync/old-versions/rsync-2.6.1-NEWS">release NEWS</a> for the full
 130 details.
 131
 132 <a name="security_apr04"></a>
 133 <h3 style="color:red">April 2004 Security Advisory</h3>
 134
 135 <p>There is a security problem in all versions prior to 2.6.1 that affects only
 136 people running a read/write daemon WITHOUT using chroot.  If the user privs
 137 that such an rsync daemon is using is anything above "nobody", you are at risk
 138 of someone crafting an attack that could write a file outside of the module's
 139 "path" setting (where all its files should be stored).  Please either enable
 140 chroot or upgrade to 2.6.1.  People not running a daemon, running a read-only
 141 daemon, or running a chrooted daemon are totally unaffected.
 142
 143 <p>See the <a href="download.html">download page</a> for all the ways
 144 to grab the new version.
 145
 146 <h3>One Cygwin hang-problem resolved</h3>
 147
 148 <p>The problem with rsync hanging at the end of the transfer on
 149 <a href="http://www.cygwin.com/">Cygwin</a> had been previously traced to a
 150 signal-handling bug in their compatibility DLL.  This bug appears to now be
 151 fixed in DLL version 1.5.7-1, and Cygwin users are reporting that upgrading the
 152 DLL removes the hang-at-end-of-transfer problem for their existing rsync executable.
 153 (Note that this doesn't solve a hang that some folks see in the middle of a
 154 transfer -- using daemon mode instead of ssh can work around that one.)
 155
 156 <a name="two_six"></a>
 157 <h3>Rsync 2.6.0 released</h3>
 158
 159 <p>January 1st, 2004
 160
 161 <P> Two important things to note in the new release:
 162
 163 <ol>
 164
 165 <li>The default remote shell is now "ssh" unless you tell configure you want to
 166 make something else the default.
 167
 168 <li>Some bug fixes in the include/exclude code, while making things work
 169 properly, have resulted in some user-visible changes for certain wildcard
 170 strings.  Read the BUG FIXES below to see if any of these changes apply to you.
 171 (Most people should be unaffected.)
 172
 173 </ol>
 174
 175 <p>One other item of note is that the oft-requested option "--files-from" is now
 176 available.  This option lets you specify a list of files to transfer, and can
 177 be much more efficient than a recursive descent using include/exclude
 178 statements (if you know in advance what files you want to transfer).  The list
 179 of files can come from either side of the connection, so it is possible for a
 180 server to provide the file-list that lets someone grab a server-specified set of
 181 files, for example.  See the <a href="/ftp/rsync/rsync.html">rsync man page</a>
 182 for more details.
 183
 184 <p>For a full list of changes in version 2.6.0, see the
 185 <a href="/ftp/rsync/old-versions/rsync-2.6.0-NEWS">release NEWS</a>.
 186
 187 <a name="security_dec03"></a>
 188 <h3 style="color:red">December 2003 Security Advisory</h3>
 189
 190 <p>December 4th, 2003
 191
 192 <h4>Background</h4>
 193
 194 <p>The rsync team has received evidence that a vulnerability in rsync was
 195 recently used in combination with a Linux kernel vulnerability to
 196 compromise the security of a public rsync server. While the forensic
 197 evidence we have is incomplete, we have pieced together the most
 198 likely way that this attack was conducted and we are releasing this
 199 advisory as a result of our investigations to date.
 200
 201 <p>
 202 Our conclusions are that:
 203
 204 <ul>
 205
 206 <li>rsync version 2.5.6 and earlier contains a heap overflow vulnerability that can
 207    be used to remotely run arbitrary code.
 208
 209 <li>While this heap overflow vulnerability could not be used by itself
 210    to obtain root access on a rsync server, it could be used in
 211    combination with the recently announced brk vulnerability in the
 212    Linux kernel to produce a full remote compromise.
 213
 214 <li>The server that was compromised was using a non-default rsyncd.conf
 215    option <tt>"use chroot = no"</tt>. The use of this option made the attack on
 216    the compromised server considerably easier. A successful attack is
 217    almost certainly still possible without this option, but it would
 218    be much more difficult.
 219 </ul>
 220
 221 <p>
 222 Please note that this vulnerability only affects the use of rsync as a
 223 "rsync server". To see if you are running a rsync server you should
 224 use the netstat command to see if you are listening on TCP port
 225 873. If you are not listening on TCP port 873 then you are not running
 226 a rsync server.
 227
 228 <h4>New rsync release</h4>
 229
 230 <p>
 231 In response we have released a new version of rsync, version
 232 2.5.7. This is based on the current stable 2.5.6 release with only the
 233 changes necessary to prevent this heap overflow vulnerability. There
 234 are no new features in this release.
 235 <p>
 236 We recommend that anyone running a rsync server take the following
 237 steps:
 238 <ol>
 239 <li>
 240  Update to (at least) rsync version 2.5.7 immediately.
 241 <li>
 242  If you are running a Linux kernel prior to version 2.4.23 then
 243       you should upgrade your kernel immediately. Note that some
 244       distribution vendors may have patched versions of the 2.4.x
 245       series kernel that fix the brk vulnerability in versions before
 246       2.4.23. Check with your vendor security site to ensure that you
 247       are not vulnerable to the <tt>brk</tt> problem.
 248 <li>
 249  Review your <tt>/etc/rsyncd.conf</tt> configuration file. If you are
 250       using the option <tt>"use chroot = no"</tt> then remove that line or
 251       change it to <tt>"use chroot = yes"</tt>.  If you find that you need that
 252       option for your rsync service then you should disable your rsync
 253       service until you have discussed a workaround with the rsync
 254       maintainers on the rsync mailing list.  The disabling of the
 255       chroot option should not be needed for any normal rsync server.
 256 </ol>
 257
 258 <p>The patches and full source for rsync version 2.5.7 are available from
 259 <a href="http://rsync.samba.org/">http://rsync.samba.org/</a> and mirror sites. We expect that vendors will
 260 produce updated packages for their distributions shortly.
 261
 262 <h4>Credits</h4>
 263
 264 <p>
 265 The rsync team would like to thank the following individuals for their
 266 assistance in investigating this vulnerability and producing this
 267 response:
 268 <ul>
 269
 270 <li>Timo Sirainen &lt;tss.iki.fi&gt;
 271 <li>Mike Warfield &lt;mhw.wittsend.com&gt;
 272 <li>Paul Russell &lt;rusty.samba.org&gt;
 273 <li>Andrea Barisani &lt;lcars.gentoo.org&gt;
 274 </ul>
 275
 276 <p>
 277 The Common Vulnerabilities and Exposures project (cve.mitre.org) has
 278 assigned the name
 279 <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0962">CAN-2003-0962</a>
 280 to this issue.
 281
 282 <p>
 283 Regards,
 284 <p>
 285 The rsync team
 286
 287 <!--#include virtual="footer.html" -->