Bug 877279

Summary: CVE-2012-2251 rssh: insufficient filtering of -e option for rsync [fedora-all]
Product: [Fedora] Fedora Reporter: James Clawson <temp66>
Component: rsshAssignee: Huzaifa S. Sidhpurwala <huzaifas>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: jlieskov, security-response-team, temp66
Target Milestone: ---Keywords: Security, SecurityTracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-19 03:34:14 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 880174    
Attachments:
Description Flags
debian patch for issue
none
updated debian patch for issue
none
Update to 2.3.4 none

Description James Clawson 2012-11-16 01:38:43 EST
Description of problem:
rssh 2.3.3-3 as found in fc17 seems to insufficiently filter the -e option when using rsync. The regular expression is flawed and permits rsync to be invoked as a client with the -e option as long as the argument is a relative path and does not contain the letter 'e'.


Here is an example of a command that will be permitted by rssh:
rsync -e./script.sh  localhost:/tmp--server ./

rsync (at least version 3.0.9-4) will attempt to execute ./script.sh when invoked this way.

Placing a space after the -e results in the command being rejected as expected.
Comment 1 Jan Lieskovsky 2012-11-20 10:30:01 EST
Thank you for your report, James.

The above behaviour is documented in the rssh manual page (section Command Line Parser):
 
"As of rssh version 2.2.3, the program must parse out the complete command line to avoid command line options which cause the execution of arbitrary programs (and  hence  bypass  the  security of rssh). In order to keep the program source code sane, the parser is a little over-zealous about matching command line options.  In practice, this probably will not be an issue, but in theory it is possible.

If you run into a problem where rssh refuses to run, claiming to be rejecting insecure command line options which were not specified, try changing your command line such that all short options are specified as single-letter option flags (e.g. -e -p instead of -ep) and make sure you separate arguments from their respective options by a space (e.g. -p 123 instead of -p123). In virtually all cases, this should solve the problem. Admittedly, an exhaustive search was not performed, but no problematical cases were found which were likely to be common.

The alternative would have been to include a complete command-line parser for rcp, rdist, and rsync; this was way out of the scope of this project. In practice, the existing parser should suffice. If, however, you find cases where it does not, please post details to the rssh mailing list. Details about how to post to the mailing list can be found at the rssh homepage."

To get this bug correct, you should report the above use case to rssh mailing list, as suggested above.

Since this issue is triggerable via command line only and depends on the position of argument provided after the -e option, it is not a security flaw.

But I have kept this bug report in private group to keep it private (since it was originally reported that way).

Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team
Comment 3 Tomas Hoger 2012-11-20 12:05:48 EST
(In reply to comment #1)
> The above behaviour is documented in the rssh manual page (section Command
> Line Parser):

My reading is that the man page explains a workaround for a case when some argument is rejected when it should not be.  James' report is about a case when argument is not rejected when it should be.
Comment 4 James Clawson 2012-11-20 12:33:19 EST
That is correct. The issue is that the command is not being rejected when it should be.

FYI: I saw that the debian version is vulnerable as well and submitted a patch for it (it was a one line fix for their version). The (debian) package maintainer added to the patch and is testing it right now. Their patch can be used as the basis for a fix for the FC version.
Comment 5 Jan Lieskovsky 2012-11-20 12:37:20 EST
(In reply to comment #4)

Thanks. Taking back, this truly is a security flaw.

> That is correct. The issue is that the command is not being rejected when it
> should be.
> 
> FYI: I saw that the debian version is vulnerable as well and submitted a
> patch for it (it was a one line fix for their version). The (debian) package
> maintainer added to the patch and is testing it right now. Their patch can
> be used as the basis for a fix for the FC version.

So right now the status is we are waiting for the Debian maintainer to provide a patch. Or should we (Red Hat Security Response Team) contact Derek Martin / upstream directly to provide a patch (he mentions direct contact in the manual page and we have previous experiences with cooperation with him, so can do that if you wish / if it's desired).

Just let us know.

Thanks, Jan.
Comment 6 Tomas Hoger 2012-11-20 12:41:35 EST
(In reply to comment #4)
> FYI: I saw that the debian version is vulnerable as well and submitted a
> patch for it (it was a one line fix for their version). The (debian) package
> maintainer added to the patch and is testing it right now. Their patch can
> be used as the basis for a fix for the FC version.

Can you attach it here too?
Comment 7 James Clawson 2012-11-20 12:54:46 EST
Created attachment 648691 [details]
debian patch for issue

Applies to Debian version 2.3.2-13
Comment 8 James Clawson 2012-11-20 13:32:00 EST
Created attachment 648713 [details]
updated debian patch for issue

This is an updated patch the Debian maintainer created that also fixes a related security issue (that --server could be hidden as an argument to another option).
Comment 9 James Clawson 2012-11-20 13:34:08 EST
Also, the Debian folks are assigning a CVE to this, no need for you guys to as well.
Comment 10 Tomas Hoger 2012-11-21 10:04:49 EST
For posterity, this bug should not affect upstream rssh 2.3.3 version.  AFAICS, the problem is introduced by the patch that adds rsync 3.x support, taken from the Debian rssh packages:

http://pkgs.fedoraproject.org/cgit/rssh.git/tree/rssh-2.3.3-rsync-protocol.patch?id=294f47a35da41ba3596a57af71e98cd5dee797d4

The fix from comment 7 / comment 8 is not directly applicable to rssh packages in Fedora, which are still missing the fix for CVE-2012-3478 (bug 820414).

rssh is reportedly dead upstream too, and like to get retired from Fedora (bug 820415, comment 2).  It's already orphaned.

http://seclists.org/bugtraq/2012/May/35
Comment 11 James Clawson 2012-11-21 14:14:44 EST
This has been assigned CVE-2012-2251.
Comment 13 Tomas Hoger 2012-11-28 03:08:33 EST
Public now via Debian advisory:

http://www.debian.org/security/2012/dsa-2578
Comment 14 Tomas Hoger 2012-11-28 03:21:49 EST
Upstream rssh 2.3.4 also fixes another issue known under CVE-2012-2252 (bug 880177).
Comment 15 Tomas Hoger 2012-12-10 12:52:02 EST
Created attachment 660999 [details]
Update to 2.3.4

This updates Fedora package to upstream 2.3.4 and corrects all outstanding security issues (i.e. also bug 820415 and bug 880991).  It still needs fedpkg new-sources before getting committed, relevant sources are:

5211f5fe206704f813a3cec61f487042  rssh-2.3.4.tar.gz
99ee2985b4f2bc53d8c6b074e7c816e0  rssh-2.3.4.tar.gz.sig
Comment 16 Fedora Update System 2012-12-10 13:49:00 EST
rssh-2.3.4-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/rssh-2.3.4-1.fc18
Comment 17 Fedora Update System 2012-12-10 14:15:46 EST
rssh-2.3.4-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/rssh-2.3.4-1.fc17
Comment 18 Fedora Update System 2012-12-10 20:32:22 EST
Package rssh-2.3.4-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rssh-2.3.4-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20109/rssh-2.3.4-1.fc17
then log in and leave karma (feedback).
Comment 19 Fedora Update System 2012-12-11 04:38:11 EST
rssh-2.3.4-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/rssh-2.3.4-1.fc16
Comment 20 Fedora Admin XMLRPC Client 2012-12-11 05:04:28 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 21 Fedora Update System 2012-12-19 03:34:16 EST
rssh-2.3.4-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2013-01-11 19:59:55 EST
rssh-2.3.4-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.