Command Execution Vulnerability in rssh with allowscp (CVE-2019-1000018)
We discovered a vulnerability in rssh where users could bypass the “allowscp” option into arbitrary command execution.
This issue is pending CVE assignment.
From the rssh home page:
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.
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.
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:
From the command line:
ssh rssh_user@host 'scp -o PKCS11Provider=./bad.so 1 localhost:
Using the default .ssh/config file (uploaded to the server first):
ssh rssh_user@host 'scp 1 localhost:
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, its contents should be:
For a detailed write-up of how we discovered this issue, see our SANS 2018 Holiday Hack report.
The author of rssh replied to our report saying that the software is no longer maintained.
Russ Allbery sent a patch that is “COMPLETELY UNTESTED,” but might fix the problem. See:
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, e-mailed rssh-discuss list
Jan 22, 2019: CVE-2019-1000018 assigned
This issue was discovered by the ESnet Security Team. It was discovered as part of our participation in the SANS 2018 Holiday Hack Challenge. For more details about the Holiday Hack, you can also see our report.
(Tracked in git)
Jan 16, 2019: Fixed the publication date, and corrected two typos.