rssh (was Re: Subversion (oh, and PHP5))
Derek Martin
invalid at pizzashack.org
Tue Dec 28 11:00:01 EST 2004
On Mon, Dec 27, 2004 at 04:48:16PM -0500, Bill McGonigle wrote:
> On Dec 27, 2004, at 3:37 PM, Cole Tuininga wrote:
>
> >Be aware that Derek has (I believe) ceased maintaining rssh, and there
> >has been (IIRC) at least one vulnerability reported since he stopped
> >maintaining it.
> >
> >I don't remember what the bug was or the severity of it though.
>
> The last update was two months ago and I don't see any evidence on the
> site that it's abandoned. I'm definitely interested if you have any
> info to that effect.
First, since you're using rssh to allow sftp, you're ok -- no holes
(unless you allow scp as well).
Second, the vulnerability is not a root compromise... It's a
compromise that allows users to gain access to run arbitrary programs
AS THEMSELVES on the target machine, maybe. You can prevent this, if
you're careful.
Third, if you know your users, and you know they're a) honest and/or
b) not sophisticated, you probably don't need to worry. (But then,
you might not have need for this kind of application in the first
place.)
The problem is that the scp, rsync, and rdist programs have command
line options which allow the user to specify a command to run for the
purpose of setting up a remote connection. This allows a user to run
a command such as this:
ssh user at targethost scp -S /path/to/myprog
This allows the user to run basically any program they can access. So
how do you prevent this?
1. To keep them from running arbitrary system commands, put the user
in a chroot jail. Make sure you only include the bare minimum of
stuff to get the chroot jail working.
2. To keep them from running their OWN arbitrary programs, keep their
files on a separate partition, and mount the partition with the noexec
option.
That's it. This may not work for everyone, for example if the host in
question is hosting a web server and the user needs to be able to
execute scripts. Or if you can't make the users' files live on their
own separate partition for some reason.
As for maintaining the program... I do intend to fix this problem
eventually, if no one does it first; but these days I don't have a lot
of time to work on rssh. Of course, it shouldn't need a lot of
maintenance... The functionality is complete, and the only
maintenance needed would be bug fixes. The code's been looked at
fairly carefully for buffer overruns and format string
vulnerabilities, so I'm fairly confident that there aren't any. The
code's been in use by quite a few people for quite a while, so I'm
reasonably certain that there aren't any functionality bugs. Once
this problem is fixed, I'm reasonably confident that no further
maintenance will be required, unless there are future changes to the
programs it supports (scp, sftp, rdist, rsync, cvs).
It's worth noting that there isn't a problem with CVS, nor with sftp.
When used with sftp, rssh exec()'s sftp-server, which does not have
command-line options. As far as I was able to determine, CVS doesn't
have any command-line options which allow for arbitrary programs to be
executed.
It's also worth noting that the problem is more complicated than one
might naively think. It may seem like you can solve it by simply
stripping out such command-line options from the argv list. In theory
that's right, but the problem is that you can specify arguments like
this:
scp -pqrv1Sfoo blah blah
Which will execute the program foo in the current $PATH. So the
problem involves finding occurrences of S in an option string, and
verifying that it is not part of a potentially legitimate command-line
option. This is not a difficult problem, just time-consuming.
The scp program would actually be relatively easy to fix... The
command line is always basically the same (so you could allow only
those specific options). But the other programs are more complex, and
would require detailed parsing of the command line options.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20041228/599d18b7/attachment.bin
More information about the gnhlug-discuss
mailing list