security.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3 <HEAD>
   4 <TITLE>rsync</TITLE>
   5 <style>
   6 .security { color: red; }
   7 h3 { margin-bottom: 0px; }
   8 .date { color: #D25A0B; }
   9 </style>
  10 </HEAD>
  11 <!--#include virtual="header.html" -->
  12
  13 <H2 align="center">Rsync Security Advisories</H2>
  14
  15 <p><a name="s3_1_3"></a><hr>
  16 <h3>File-list validation in 3.1.3</h3>
  17 <i class=date>January 28st, 2018</i>
  18
  19 <p>If you are using a version of rsync older than 3.1.3 as a client and
  20 receiving xattrs from an rsync server that you might not fully trust, a
  21 malicious (modified) server could send a non-null-terminated xattr name to
  22 overflow the xattr read buffer.
  23
  24 <p>If you are running a writable rsync daemon older than 3.1.3, you should add
  25 a rule "refuse options = protect-args" if you don't fully trust the users who
  26 are sending you files.
  27
  28 <p><a name="s3_1_2"></a><hr>
  29 <h3>File-list validation in 3.1.2</h3>
  30 <i class=date>December 21st, 2015</i>
  31
  32 <p>If you're using a version of rsync older than 3.1.2 as a client and
  33 receiving files from an rsync server that you might not fully trust, this
  34 version adds extra checking to the file list to prevent the sender from
  35 tweaking the paths and/or the transfer requests in a way that could cause
  36 a file to be received outside the transfer destination.
  37
  38 <p><a name="s3_0_2"></a><hr>
  39 <h3>Xattr security fix in 3.0.2</h3>
  40 <i class=date>April 8th, 2008</i>
  41
  42 <p>If you're using a version of rsync from 2.6.9 to 3.0.1 that has extended
  43 attribute (xattr) support enabled, you should upgrade to 3.0.2 to avoid a
  44 potential buffer overflow problem.  All 3.x versions have the potential to
  45 support xattrs (depending on OS availability and the configure options used),
  46 but version 2.6.9 had to be patched for this support.  You can run the command
  47 "rsync --version" and look for the string "xattrs" (as long as it is not
  48 "no&nbsp;xattrs") to see if your rsync is affected.
  49
  50 <p>For those running affected versions, there is
  51 <a href="https://download.samba.org/pub/rsync/security/rsync-3.0.1-xattr-alloc.diff">a
  52 patch with the fix available</a>.
  53
  54 <p>Those running a writable rsync daemon can opt to refuse the "xattrs" option
  55 as a way to avoid the problem without an upgrade:
  56
  57 <blockquote><pre>refuse options = xattrs</pre></blockquote>
  58
  59 <p>(If you already refuse options, be sure to append "xattrs" to your existing
  60 config parameter rather than adding another refuse directive.)
  61
  62 <p><a name="s3_0_0"></a><hr>
  63 <h3>Daemon security fixes in 3.0.0 (with patches for 2.6.9)</h3>
  64 <i class=date>First published on November 28th, 2007;<br>
  65 Updated on December 16th, 2007;<br>
  66 Item 3 added on February 15th, 2008</i>
  67
  68 <p>Three security advisories affect people who run a <b>writable</b> rsync
  69 daemon:  The first affects only those with "use chroot = no" (which is not a
  70 very safe combination in general), the second affects a daemon that has
  71 daemon-excluded files that are being hidden in a module's hierarchy, and
  72 the third affects only those with "use chroot = yes".
  73 Included are simple config-change suggestions that should help you to
  74 avoid the security issues and patches that make things safer.
  75 These advisories affect all rsync versions.
  76
  77 <h4>1. Daemon advisory for "use chroot = no"</h4>
  78
  79 <p>If you are running a writable rsync daemon with "use chroot = no", there
  80 is at least one way for someone to trick rsync into creating a symlink
  81 that points outside of the module's hierarchy.
  82
  83 <p>This means that if you are allowing access from users who you don't
  84 trust, that you should either figure out a way to turn on "use chroot",
  85 or configure the daemon to refuse the "links" option (see "refuse
  86 options" in the rsyncd.conf manpage) which will disable the ability of
  87 the rsync module to receive symlinks.  After doing so, you should also
  88 check that any existing symlinks in the daemon hierarchy are safe.
  89
  90 <p>Starting with the 3.0.0-pre6 release, there is a new daemon parameter
  91 available: "munge symlinks".  This allows an rsync daemon to accept
  92 symlinks and return them intact (with even a leading slash still there,
  93 which is new for a non-chroot daemon), but will not allow the symlinks
  94 to be used while they are in the daemon's hierarchy.
  95
  96 <p>For those running
  97 2.6.9, there is
  98 <a href="https://download.samba.org/pub/rsync/security/rsync-2.6.9-munge-symlinks.diff">a
  99 patch for 2.6.9 to implement this parameter</a>.
 100
 101 <p>Any admin applying that patch should read the "munge symlinks" section
 102 of the modified rsyncd.conf manpage for more information.  You can also
 103 read about this parameter in the
 104 <a href="https://download.samba.org/pub/rsync/rsyncd.conf.html">rsyncd.conf
 105 manpage from a 3.x version</a>.
 106
 107 <h4>2. Daemon advisory for daemon excludes</h4>
 108
 109 <p>If you are running a writable rsync daemon that is using one of the
 110 "exclude", "exclude from", or "filter" parameters in the rsyncd.conf file
 111 to hide data from your users, you should be aware that there are tricks
 112 that a user can play with symlinks and/or certain options that can allow
 113 a user that knows the name of a hidden file to access it or overwrite it
 114 (if file permissions allow that).
 115
 116 <p>You can avoid the symlink problem using the suggestions in the advisory
 117 above.
 118
 119 <p>When a daemon has "use chroot = no" set , there was some buggy
 120 exclude-checking for these options: <code>--compare-dest</code>,
 121 <code>--link-dest</code>, <code>--copy-dest</code>, <code>--partial-dir</code>,
 122 <code>--backup-dir</code>, <code>--temp-dir</code>, and
 123 <code>--files-from</code>.  These are fixed in the 3.0.0pre7 release.  For
 124 those running 2.6.9, there is <a
 125 href="https://download.samba.org/pub/rsync/security/rsync-2.6.9-daemon-exclude.diff">a patch for
 126 2.6.9</a> to fix these checks.
 127
 128 <p>Some of the above options can still cause problems if an excluded
 129 sub-directory or filename is inside the option's directory hierarchy and the
 130 names of a transferred file clashes with it.  The affected options are the
 131 various <code>--*-dest</code> options (of which only <code>--link-dest</code>
 132 is particularly worrisome),
 133 <code>--backup-dir</code>, and <code>--partial-dir</code>.
 134
 135 <p>You can avoid these sub-path problems by putting the following "refuse
 136 options" setting into your rsyncd.conf file:
 137
 138 <blockquote><pre>refuse options = link-dest backup-dir partial-dir</pre></blockquote>
 139
 140 <p>Those who aren't using an rsync with the latest exclude fixes may want to add
 141 some of the other affected options as well.
 142
 143 <h4>3. Daemon advisory for "use chroot = yes"</h4>
 144
 145 <p>If you are running a writable rsync daemon with "use chroot = yes", you
 146 should take care that users cannot upload their own library files and attempt
 147 to load them.
 148
 149 <p>Beginning with rsync 3.0.0pre10, you can specify an inside-chroot path that
 150 makes the top of the transfer a subdirectory inside the chroot area, and that
 151 automatically makes library loading occur outside the transfer area (assuming
 152 you didn't pick an unwise subdirectory name for the transfer area and you
 153 don't have symlinks that point outside the transfer area).
 154
 155 <p>If that solution is not good for you, the easiest way to protect your daemon
 156 is to create some appropriate directories in the top of your module's path
 157 hierarchy, such as "/etc", "/lib", and "/usr" (and any other top-level dirs
 158 that might be in the load path), chown those directories to some other user
 159 than the one that the module runs as (so that rsync will not be able to write
 160 files there, assuming that it is not run as root), and then hide the dirs using
 161 an exclude directive (either add a new one or extend your existing one):
 162
 163 <blockquote><pre>exclude = /etc /lib /usr</pre></blockquote>
 164
 165 <p>Doing all that will assure you that no user will be able to use rsync to
 166 upload a library that can be potentially loaded while rsync is attempting to
 167 perform an action, such as translating a username.  You can feel free to put
 168 trusted libraries that you want rsync to access in the protected hierarchies,
 169 as desired.
 170
 171 <p>Also available in rsync 3.0.0pre10 is a new daemon parameter that allows you
 172 to avoid the accessing of user/group-name translation libraries by a chrooted
 173 rsync:  the "numeric ids" daemon parameter lets you turn on a forced
 174 numeric-only mode.  The default for a chroot module is to enable this
 175 parameter, while the default for a non-chroot module is to disable it.
 176
 177 <p>For those running 2.6.9, there is <a
 178 href="https://download.samba.org/pub/rsync/security/rsync-2.6.9-daemon-ids.diff">a patch for
 179 2.6.9</a> to add the "numeric ids" daemon config parameter.  (The patch will
 180 only apply cleanly if you've already applied the munge-symlinks diff mentioned
 181 above.)
 182
 183 <p><a name="s2_6_8"></a><hr>
 184 <h3>Xattr security fix in 2.6.8</h3>
 185 <i class=date>April 22th, 2006</i>
 186
 187 <p>If you're using a version of rsync prior to 2.6.8 that was patched to
 188 include extended attribute (xattr) support, you should upgrade to 2.6.8 or
 189 later to avoid a potential buffer overflow problem.
 190
 191 <p><a name="s2_6_6"></a><hr>
 192 <h3>Zlib security fix in 2.6.6</h3>
 193 <i class=date>July 28th, 2005</i>
 194
 195 <p>If you're using a version of rsync prior to 2.6.6, there is a potential
 196 null-pointer security bug in the zlib code.  You can avoid its affect in an
 197 rsync daemon situation by configuring rsync to refuse the "compress" option.
 198
 199 <p><a name="s2_6_3"></a><hr>
 200 <h3>Daemon path-sanitizing fix in 2.6.3</h3>
 201 <i class=date>August 12th, 2004</i>
 202
 203 <p>There is a path-sanitizing bug that affects daemon-mode in
 204 rsync versions prior to 2.6.3, but only if "use chroot" is disabled.  It
 205 does <b>not</b> affect the normal send/receive filenames that specify what
 206 files should be transferred (this is because these names happen to get
 207 sanitized twice, and thus the second call removes any lingering leading
 208 slash(es) that the first call left behind).  It does affect certain
 209 option paths that cause auxiliary files to be read or written.
 210
 211 <p>One potential fix that doesn't require recompiling rsync is to set
 212 "use chroot = true" for all the modules in the rsyncd.conf file.
 213
 214 <p><a name="s2_6_1"></a><hr>
 215 <h3>Daemon security fix in 2.6.1</h3>
 216 <i class=date>April 26th, 2004</i>
 217
 218 <p>There is a security problem in all versions prior to 2.6.1 that affects only
 219 people running a read/write daemon with "use chroot" disabled.  If the user privs
 220 of a module in the daemon config is anything above "nobody", you are at risk
 221 of someone crafting an attack that could write a file outside of the module's
 222 "path" setting (where all its files should be stored).  Please either enable
 223 chroot or upgrade to 2.6.1.  People not running a daemon, running a read-only
 224 daemon, or running a chrooted daemon are totally unaffected.
 225
 226 <p><a name="s2_5_7"></a><hr>
 227 <h3>Memory overflow fix in 2.5.7</h3>
 228 <i class=date>December 4th, 2003</i>
 229
 230 <p>Rsync versions prior to 2.5.7 contain a heap overflow vulnerability that
 231 could be used to remotely run arbitrary code, but this only affects the use of
 232 rsync as an "rsync daemon" (where rsync handles incoming socket connections,
 233 typically on port 873).
 234
 235 <!--#include virtual="footer.html" -->
 236 <br>&nbsp;
 237 <br>&nbsp;
 238 <br>&nbsp;
 239 <br>&nbsp;
 240 <br>&nbsp;
 241 <br>&nbsp;
 242 <br>&nbsp;
 243 <br>&nbsp;
 244 <br>&nbsp;
 245 <br>&nbsp;
 246 <br>&nbsp;
 247 <br>&nbsp;
 248 <br>&nbsp;