DO NOT REPLY [Bug 1890] TLS for rsync protocol

samba-bugs at samba-bugs at
Sun Aug 9 04:33:37 MDT 2009

------- Comment #9 from devzero at  2009-08-09 05:33 CST -------
> It's easy to tell an ssh server to restrict what commands can be run.
is that really secure? i think, no.

found this one on the scponly pages:

SECURITY PROBLEM 2, reported by Pekka Pessi

If ANY the following conditions are true, administrators using scponly-4.1 or
older may be at risk of remote scponly users circumventing the restricted shell
and executing arbitrary programs. There is no privilege escalation and this
vulnerability is post-authentication.

    * scp compatibility is enabled
    * rsync compatibility is enabled 


To exploit this vulnerability, a remote scponly user could:

    * construct a malicious command line argument to either the rsync or scp.
Athough scponly does check for arguments that allow the user to specify a
program to run, it does not use getopt() style processing to locate these
potentially malicious arguments. For example, the potentially malicious scp
argument "-S program" would be detected but by combining it with the benevolent
"-v" (yielding "-vS program") would not. 


The new release of scponly-4.2 has:

    * getopt to process the arguments to scp and rsync.
    * no support rsync or scp by default. henceforth, the recommended means to
use scponly is via sftp
    * other fixes and features
    * fix for openbsd ldd in setup_chroot
    * sftp-logging compatibility patch
    * fix for autoconf AC_INIT macro
    * patch for command line args to setup_chroot invocation
    * patches to fix passw 

here is some more interesting article which shows, that this is sorta hackerish

Configure bugmail:
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the rsync mailing list