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/>
_______________________________________________ rssh-discuss mailing list rssh-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rssh-discuss
