Thread: rssh vulnerabilities in rsync support
Brought to you by:
xystrus
From: Russ A. <ea...@ey...> - 2019-02-02 19:21:58
Attachments:
0007-Verify-rsync-command-options.patch
|
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/> |