[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rssh-discuss
Subject:    Re: rssh Vulnerability: Command Execution with allowscp
From:       Russ Allbery <eagle () eyrie ! org>
Date:       2019-01-29 5:50:36
Message-ID: 878sz4au6r.fsf () hope ! eyrie ! org
[Download RAW message or body]

Derek Martin <code@pizzashack.org> 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 (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>


_______________________________________________
rssh-discuss mailing list
rssh-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rssh-discuss
[prev in list] [next in list] [prev in thread] [next in thread]