Re: rssh Vulnerability: Command Execution with allowscp
Brought to you by:
xystrus
From: Russ A. <ea...@ey...> - 2019-01-29 05:50:50
|
Derek Martin <co...@pi...> writes: > Yes, although given how hard solving this problem actually is, I don't > think there exists any workable solution (for the general case--see > below). By the way, AFAICT, the only reasonable alternative to RSSH I > know of is scponly, and it looks like it was last updated less recently > than RSSH was. I can't speak to how good a job it does at closing up > all the holes as I've not tried to evaluate that since circa 2003. rush showed up a little while ago in Debian: http://puszcza.gnu.org.ua/software/rush/ I looked through the documentation a bit, but haven't really examined it. It has a rather complex configuration language that lets you write various rules specifying what to allow and deny, but I'm pretty dubious that it's possible to write good enough rules to make this safe. rsync comes with a script called rrsync that provides rssh-like functionality only for the server side of rsync. It fully parses the command line and tries to make sure that people don't rsync outside of a particular path, and apparently processes rsync source code to figure out what options to allow. It *might* be safe? > The task wass complicated further by people continually asking for > support for additional programs or features (which pretty much > universally were very obviously not securable, FWIW), and my own caving > to some of those requests (CVS, rsync in particular) when I should've > known better... As Russ says, these things keep cropping up, as OS > features, OpenSSH features, or features of the other tools RSSH is meant > to safeguard, evolve. Yeah, there were a ton more requests for new programs in both Debian and Ubuntu, and I said yes to one of them (svnserve) and then learned my lesson and said no to all the rest. People really want some sort of safe remote restricted shell for various commands, but doing this as a very simple general wrapper is extremely hard. > For serious security applications, RSSH should be considered > insecurable, and unmaintained, from this point on. One of these days, I > should really get around to updating the website to reflect that... > My thanks to Russ for his efforts with the Debian package, and for > providing some level of support when I was not paying much attention, > for so long. Thank you for providing a really useful tool! I've made a lot of use of it over the years as defense in depth where the other end is semi-privileged, so I'm not super-worried, but I'd still rather limit the blast radius if something goes wrong. (Mostly for internal backups via rsync, to be honest.) It's been a good run. :) Alas, security is really hard. I may write some really stripped-down version of the same basic idea for my own use that ignores the command sent by the client and just always runs rsync --server with a bunch of standard options. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |