Committing a change I made last month but neglected to check in.
[rsync-web.git] / 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>November 28th, 2007 (updated December 16th, 2007)</i>
18
19 <p>Two security advisories affect people who run a writable rsync
20 daemon:  The first affects only those with "use chroot = no" (which is not a
21 very safe combination in general), and the second affects a daemon that has
22 daemon-excluded files that are being hidden in a module's hierarchy.
23 Included are simple config-change suggestions that should help you to
24 avoid the security issues.  These advisories affect all rsync versions.
25
26 <h4>1. Daemon advisory for "use chroot = no"</h4>
27
28 <p>If you are running a writable rsync daemon with "use chroot = no", there
29 is at least one way for someone to trick rsync into creating a symlink
30 that points outside of the module's hierarchy.
31
32 <p>This means that if you are allowing access from users who you don't
33 trust, that you should either figure out a way to turn on "use chroot",
34 or configure the daemon to refuse the --links option (see "refuse
35 options" in the rsyncd.conf manpage) which will disable the ability of
36 the rsync module to receive symlinks.  After doing so, you should also
37 check that any existing symlinks in the daemon hierarchy are safe.
38
39 <p>Starting with the 3.0.0-pre6 release, there is a new daemon option
40 available: "munge symlinks".  This allows an rsync daemon to accept
41 symlinks and return them intact (with even a leading slash still there,
42 which is new for a non-chroot daemon), but will not allow the symlinks
43 to be used while they are in the daemon's hierarchy.  For those running
44 2.6.9, there is
45 <a href="http://rsync.samba.org/ftp/rsync/munge-symlinks-2.6.9.diff">a
46 patch for 2.6.9 to implement this option</a>.
47
48 <p>Any admin applying that patch should read the "munge symlinks" section
49 of the modified rsyncd.conf manpage for more information.  You can also
50 read about this option in the
51 <a href="http://rsync.samba.org/ftp/rsync/rsyncd.conf.html">rsyncd.conf
52 manpage from the development release</a>.
53
54 <h4>2. Daemon advisory for daemon excludes</h4>
55
56 <p>If you are running a writable rsync daemon that is using one of the
57 "exclude", "exclude from", or "filter" options in the rsyncd.conf file
58 to hide data from your users, you should be aware that there are tricks
59 that a user can play with symlinks and/or certain options that can allow
60 a user that knows the name of a hidden file to access it or overwrite it
61 (if file permissions allow that).
62
63 <p>You can avoid the symlink problem using the suggestions in the advisory
64 above.
65
66 <p>When a daemon has "use chroot = no" set , there was some buggy
67 exclude-checking for these options: <code>--compare-dest</code>,
68 <code>--link-dest</code>, <code>--copy-dest</code>, <code>--partial-dir</code>,
69 <code>--backup-dir</code>, <code>--temp-dir</code>, and
70 <code>--files-from</code>.  These are fixed in the 3.0.0pre7 release.  For
71 those running 2.6.9, there is <a
72 href="http://rsync.samba.org/ftp/rsync/daemon-exclude-2.6.9.diff">a patch for
73 2.6.9 to fix these checks</a>.
74
75 <p>Some of the above options can still cause problems if an excluded
76 sub-directory or filename is inside the option's directory hierarchy and the
77 names of a transferred file clashes with it.  The affected options are the
78 various <code>--*-dest</code> options (of which only <code>--link-dest</code>
79 is particularly worrisome),
80 <code>--backup-dir</code>, and <code>--partial-dir</code>.
81
82 <p>You can avoid these sub-path problems by putting the following "refuse
83 options" setting into your rsyncd.conf file:
84
85 <blockquote><pre>refuse options = --link-dest --backup-dir --partial-dir</pre></blockquote>
86
87 <p>Those who aren't using an rsync with the latest exclude fixes may want to add
88 some of the other affected options as well.
89
90 <p><a name="s2_6_8"></a><hr>
91 <h3>Xattr security fix in 2.6.8</h3>
92 <i class=date>April 22th, 2006</i>
93
94 <p>If you're using a version of rsync prior to 2.6.8 that was patched to
95 include extended attribute (xattr) support, you should upgrade to 2.6.8 or
96 later to avoid a potential buffer overflow problem.
97
98 <p><a name="s2_6_6"></a><hr>
99 <h3>Zlib security fix in 2.6.6</h3>
100 <i class=date>July 28th, 2005</i>
101
102 <p>If you're using a version of rsync prior to 2.6.6, there is a potential
103 null-pointer security bug in the zlib code.  You can avoid its affect in an
104 rsync daemon situation by configuring rsync to refuse the --compress option.
105
106 <p><a name="s2_6_3"></a><hr>
107 <h3>Daemon path-sanitizing fix in 2.6.3</h3>
108 <i class=date>August 12th, 2004</i>
109
110 <p>There is a path-sanitizing bug that affects daemon-mode in
111 rsync versions prior to 2.6.3, but only if "use chroot" is disabled.  It
112 does <b>not</b> affect the normal send/receive filenames that specify what
113 files should be transferred (this is because these names happen to get
114 sanitized twice, and thus the second call removes any lingering leading
115 slash(es) that the first call left behind).  It does affect certain
116 option paths that cause auxiliary files to be read or written.
117
118 <p>One potential fix that doesn't require recompiling rsync is to set
119 "use chroot = true" for all the modules in the rsyncd.conf file.
120
121 <p><a name="s2_6_1"></a><hr>
122 <h3>Daemon security fix in 2.6.1</h3>
123 <i class=date>April 26th, 2004</i>
124
125 <p>There is a security problem in all versions prior to 2.6.1 that affects only
126 people running a read/write daemon with "use chroot" disabled.  If the user privs
127 of a module in the daemon config is anything above "nobody", you are at risk
128 of someone crafting an attack that could write a file outside of the module's
129 "path" setting (where all its files should be stored).  Please either enable
130 chroot or upgrade to 2.6.1.  People not running a daemon, running a read-only
131 daemon, or running a chrooted daemon are totally unaffected.
132
133 <p><a name="s2_5_7"></a><hr>
134 <h3>Memory overflow fix in 2.5.7</h3>
135 <i class=date>December 4th, 2003</i>
136
137 <p>Rsync versions prior to 2.5.7 contain a heap overflow vulnerability that
138 could be used to remotely run arbitrary code, but this only affects the use of
139 rsync as an "rsync daemon" (where rsync handles incoming socket connections,
140 typically on port 873).
141
142 <!--#include virtual="footer.html" -->
143 <br>&nbsp;
144 <br>&nbsp;
145 <br>&nbsp;
146 <br>&nbsp;
147 <br>&nbsp;
148 <br>&nbsp;
149 <br>&nbsp;
150 <br>&nbsp;
151 <br>&nbsp;
152 <br>&nbsp;
153 <br>&nbsp;
154 <br>&nbsp;
155 <br>&nbsp;