Command Execution Vulnerability in rssh with allowscp (CVE-2019-1000018)

Issue

We discovered a vulnerability in rssh where users could bypass the “allowscp” option into arbitrary command execution.

This issue is pending CVE assignment.

Background

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.

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 :

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:

PKCS11Provider ./bad.so

Discovery

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

Remediation

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:

Initial E-mail Follow-up E-mail with a Bugfix to the Patch

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

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. For more details about the Holiday Hack, you can also see our report.

Changes:

(Tracked in git)

Jan 16, 2019: Fixed the publication date, and corrected two typos.