Projects: rssh and scponly Class: Arbitrary command execution Public disclosure date: Thursday Dec. 02, 2004 This message is being sent to rssh and scponly package maintainers as well as the Debian security team. Most likely I've left someone out, so could someone (probably a Debian security team member) with access to vendor-sec (or whatever the current vendor security distribution method is) please forward this on to the other vendors and distributors. Thanks. The vulnerability is described in detail below. The bottom line for package maintainers is this: rssh The author has stopped working on the program and has no interest in providing a fix. He is willing to work with anyone who wants to take over maintainership. Given that the solution is most likely not going to be simple to implement, rssh is currently unmaintained, and the vulnerability affects almost all uses of rssh, distributors may wish to remove it from their archives until a comprehensive fix is available. That said, an ambitious package maintainer that wants to have a look at fixing the source code may find that a reasonable solution is only an afternoon's worth of work. I haven't look at it closely enough myself to say for sure. scponly The author, Joe Boyle <joe@sublimation.org>, has committed to providing a new version that addresses the vulnerability. He will follow up with the scponly package maintainers to provide the new source code for packaging before the public disclosure date if the new version is available before then (it should be available well before). Dec. 02 is the agreed upon date for public posting of the notice below and for the new version of scponly to be publicly released. I think that is a reasonable timeline but if anyone strongly objects do let me know. Thanks, Jason Wies --------------------------------------------------------------------------- Vulnerable applications: rssh All versions All operating systems scponly All versions All operating systems Not vulnerable: Discussion: rssh and scponly are restricted shells that are designed to allow execution only of certain preset programs. Both are used to grant a user the ability to transfer files to and from a remote host without granting full shell access. Due to the fact that most of the preset programs offer options that execute other programs, arbitrary command execution on the remote host is possible. rssh allows any of five predefined programs to be executed on the remote host depending on the configuration. Those that are known to be vulnerable in combination with the techniques described in this posting are marked with an asterisk. - scp* - sftp-server - cvs - rdist* - rsync* scponly allows a number of predefined programs to be executed on the remote host depending on compile-time options. Those that are known to be vulnerable when used with scponly: - scp - rsync - unison (*untested) The program execution options that these programs offer: rdist -P <program> rsync -e <program> scp -S <program> unison -rshcmd <program> unison -sshcmd <program> These options allow the user to specify the location of the shell to use when connecting to the remote host. No restriction is placed on what programs may be specified by these options, and rssh and scponly do not filter these options out. The end result is that although a user may be restricted by rssh or scponly to running only /usr/bin/scp, they can in fact execute any program using /usr/bin/scp -S <program>. The problem is compounded when you recognize that the main use of rssh and scponly is to allow file transfers, which in turn allows a malicious user to transfer and execute entire custom scripts on the remote machine. rssh with sftp-server does not appear to be vulnerable. rssh with cvs is also not vulnerable using these techniques. However, it is quite probable that a malicious user could check out a carefully crafted CVS repository and execute arbitrary commands using CVS's hooks interface. Examples: ssh restricteduser@remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' scp command.sh restricteduser@remotehost:/tmp/command.sh ssh restricteduser@remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' Solution: There are no workarounds for this problem. I have talked with the author of rssh, Derek Martin. He is currently indisposed for an indefinite period of time due to changing countries and having no permanent home at the present moment. Moreover he has other priorities and has lost interest in maintaining the program. He has offered to assist anyone who would like to take over maintainership of rssh, but he does not intend to provide a fix for the current problem. Given this fact, I would strongly recommend against using rssh at this time. The author of scponly, Joe Boyle, has prepared a new release that addresses the current problem. Distributor updates have been coordinated with this posting and should be made available shortly. I think the long-term solution for those needing a highly secure restricted shell is not to allow options to commands at all, but to instead store the entire command line on the remote host and allow the user only to select from the list of stored command lines. I'm not aware of any software that offers this capability today. References: http://www.pizzashack.org/rssh/index.shtml http://www.sublimation.org/scponly/
*** This bug has been marked as a duplicate of 72815 ***
Thos two bugs are likely to get resolved at different times. Reopening and using this bug to track rssh.
the debian people are talking of just punting it from their repo since the upstream author has already said he's pretty much abandoned the package due to lack of time
Opening up this is public now.
if it's vulnerable and abandoned by upstream, we should punt it as well.
hard masked in package.mask.
GLSA 200412-01 masks rssh Bug kept open since it's still in the tree
Upstream fix: http://sourceforge.net/project/showfiles.php?group_id=65349
vapier, max : feel free to bump and remove package mask. Should be released as a GLSA 200412-01 update.
2.2.3 now in portage
Thx SpanKY. GLSA 200412-01 updated.
