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