Re: rssh Vulnerability: Command Execution with allowscp
Brought to you by:
xystrus
From: Russ A. <ea...@ey...> - 2019-01-29 05:39:58
|
Russ Allbery <ea...@ey...> writes: > I suspect that the rsync protocol is also vulnerable to a version of > this same bug if .ssh/config is writable and is used as the ssh client > path and the ssh binary is available on the server side, by sending an > rsync command that tries to copy a file to localhost: similar to your > second attack example. I believe tightening rssh's check that the rsync > command line starts with --server would address that, since I think (but > haven't confirmed) that will disable remote copies. > It seems likely that there's some way of abusing cvs as well, given its > huge command surface. Hi all, I finally had a chance to dig into this a little more, since I owe rssh users in Debian stable some security support. The short version is that I think I've patched up the obvious ways to exploit this cluster of vulnerabilities via rsync or scp, but I'm not at all convinced that I've found all the other routes in (and I think it's quite likely there's some lingering way in via the cvs support, since the attack surface for cvs is just so large). Attached are three patches: the first adds argument checking for scp, the second is an update of the earlier rsync patch that tightens its argument checking and requires rsync be put into server mode (which looks like it will prevent initiation of outbound ssh connections, which would be another route to this same exploit), and the third applies argument checking to commands run inside a chroot. It turns out that rssh was never checking arguments if run via a chroot, and I didn't notice because I personally use it as a mild defense in depth where a chroot didn't feel important. (This last was pointed out to me by another list member in private email. I'm not naming you explicitly since I wasn't sure if you wanted to be mentioned on-list, but feel free to claim credit -- that was a great catch!) I've uploaded a new version of the Debian package to unstable with these fixes and will work with the Debian security team on a stable fix. However, once the new Debian package propagates to testing, I expect to request that it be removed (in advance of our upcoming new Debian stable release), so it will not be in the next release of Debian. I think it's time; we know the security model isn't the greatest, and I suspect we'll uncover more problems like this and I don't want to provide security support through another release cycle. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |