rssh vulnerabilities in rsync support

[Russ A. <ea...@ey...>]

Hi all,

We've just released another security update for the rssh package in
Debian, this time for vulnerabilities in the rsync support.  These bugs
will also affect most other installations of rssh if rsync is enabled.
Both problems were discovered by Nick Cleaton.

CVE-2019-3463

    The client could send the --daemon and --config options to the server
    and they would be passed through by rssh.  Not only does this allow
    the client to start a daemon listening on the normal rsync port, which
    is probably not desirable, but various options set in the daemon
    configuration file specified with --config allow arbitrary code
    execution.  (The most obvious is pre-xfer exec.)

CVE-2019-3463

    If rsync is built with popt (as it is in Debian), the popt library
    will attempt to open and parse ~/.popt on the server and interpret it
    as configuration for command line option parsing.  If the client can
    rsync a .popt file to the home directory of the user protected with
    rssh, this allows arbitrary code execution on the server via several
    paths.  The most obvious is via the popt exec feature which execs an
    arbitrary program as an external option filter, but a more sneaky
    approach is through the popt alias feature which allows one to alias a
    benign option (such as --server) to one that will run arbitrary code
    (such as --rsh).

The second vulnerability is an excellent example of how hard this problem
is and how the tools that rssh is attempting to provide are working
directly against its security model.  I personally had no idea that popt
even existed, having missed it in the rsync man page (which is rather
long) and not deeply investigated the shared library dependencies of
rsync.  But even if I'd known it existed, the exec feature is rather
inobvious and unexpected, as is the interaction with aliases.

The workaround for this popt issue is to unset the HOME environment
variable, which disables popt's attempt to load ~/.popt in at least the
version currently in Debian.  Note that this is fragile: if the popt
developers ever decide to fall back on getpwnam to find the home
directory, this will stop working.  A safer approach (which can't easily
be done in rssh itself) is to ensure that the home directory of an rssh
user is not writable by that user.

Attached is an updated patch for the rsync support that incorporates fixes
for these two problems, as well as a separate problem where one could hide
insecure options from rssh by passing "--" as the *argument* to some other
option that takes an argument, causing rssh to stop parsing for options
but rsync to continue parsing options.  This means that -- can no longer
be used to stop rssh's option analysis, but other normal workarounds can
be used, such as prepending ./ to paths that start with -.

As mentioned previously, I think the takeaway is that we all need to stop
using rssh and find a more robust solution.  But I'll continue to provide
security support for the Debian stable package over the lifetime of Debian
stretch if possible, since that was the commitment I made when I uploaded
the package to Debian.

-- 
Russ Allbery (ea...@ey...)              <http://www.eyrie.org/~eagle/>