James Clawson reported (see bug 877279) a flaw in the rssh, which allows an attacker to bypass checks intended to prevent invocation of rsync command with -e command line argument (which leads to execution of specified command, bypassing rssh restrictions).
This problem was reported for rssh versions as shipped in Fedora and Debian, which include additional patch adding support for rsync version 3.x. This additional patch is required, as rsync 3.x overloads -e command line argument - when --server option is also specified, -e is used to pass protocol version and additional flags. Additional info on the rsync 3.x support can be found in the following bugs:
This patch has never been accepted upstream, hence upstream versions of rssh (up to the current 2.3.3) were not affected by this problem. rssh packages in EPEL-5 also do not include this patch yet (bug 878113) and are not affected.
Public now via Debian advisory:
The issue is mentioned in the rssh 2.3.4 release announcement as an issue that did not affect upstream rssh (see comment 0 for details):
Created rssh tracking bugs for this issue
Affects: epel-6 [bug 880989]
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.
is this going to made available for the Centos 5 epository
I ask because I'm stuck with C5.8 on a number of servers and need rssh. I did try rolling my own rssh package from the published source, but without the debian patch for 2.3.4 being applied, it breaks because the connecting rsync host issuing the -e.Lsf argument.
This issue did not affect CentOS 5 as explained in comment #0. However, other issues do (bug 880992 / bug 880177 and bug 820416 / bug 820414). EPEL package maintainer has not commented on any of the related bugs yet.
If you're building from source, try rebuilding current Fedora SRPM (2.3.4-1):
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.