Thread: rssh Vulnerability: Command Execution with allowscp

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Greetings,

I'd like to make you aware of the following issue we discovered in rssh.

(Most recent version available at:
https://esnet-security.github.io/vulnerabilities/20190115_rssh)

Regards,

  --ESnet Security team

Issue:
--------

We discovered a vulnerability in rssh where users could bypass the
"allowscp" restriction and have arbitrary command execution.

Background:
-----------------

>From the rssh home page[1]:

rssh is a restricted shell for use with OpenSSH, allowing only scp and/or
> sftp. It now also includes support for rdist, rsync, and cvs. For example,
> if you have a server which you only want to allow users to copy files off
> of via scp, without providing shell access, you can use rssh to do that.

The "allowscp" option is intended to restrict users to only being able to
scp files to or from the server, and not be able to run commands on the
server.

When a user runs scp on their client, an scp command is also run on the
server. This runs through rssh (the restricted user's shell), which
attempts to verify the arguments are "secure." We can control exactly which
scp command is run on the server by supplying it as an argument to ssh. If
rssh considers our invocation secure, it will execute that command.

Exploit:
----------

The verification that rssh attempts on the scp command is incomplete. The
PKCS11Provider option will cause scp to load an arbitrary shared object
file. By uploading a malicious .so file which will execute code when
loaded, and then setting the PKCS11Provider option to that file, our scp
command will execute the code.

This option can be invoked one of three ways. In each of these methods,
we're using scp to copy a file to localhost over ssh, which causes ssh to
be invoked, loading and executing our malicious .so file.

Our setup for these commands is:

> scp bad.so rssh_user@host:

1. From the command line:
>  ssh rssh_user@host 'scp -o PKCS11Provider=./bad.so 1 localhost:'

2. Using the default .ssh/config file (uploaded to the server first):
> ssh rssh_user@host 'scp 1 localhost:'

3. By specifying our own ssh_config file (uploaded to the server first):
> ssh rssh_user@host 'scp -F rssh.config 1 localhost:'

With a config file, it's contents should be:

> PKCS11Provider ./bad.so

Discovery:
--------------

For a detailed write-up of how we discovered this issue, see our SANS 2018
Holiday Hack report[2].

Remediation:
-----------------

Unknown. The author of rssh replied to our report saying that the software
is no longer maintained.

Disclosure & Timeline:
-----------------------------

Jan 7, 2019: rssh author notified

Jan 9, 2019: rssh author replied, saying "RSSH is no longer maintained."

Jan 14, 2019: SANS notified

Jan 16, 2019: Publication, CVE requested through [Distributed Weakness
Filing](https://iwantacve.org), e-mailed rssh-discuss list

Credit:
---------

This issue was discovered by the ESnet Security Team. It was discovered as
part of our participation in the SANS 2018 Holiday Hack Challenge[3].

References:
----------------

[1] - rssh homepage: <http://www.pizzashack.org/rssh/>
[2] - ESnet Holiday Hack report: <
https://software.es.net/sans-holiday-hack-2018/#org55a074b>
[3] - SANS Holiday Hack: <https://www.holidayhackchallenge.com/2018/>