DO NOT REPLY [Bug 1890] TLS for rsync protocol

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #9 from devzero at web.de  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 

Exploit:

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. 

Fix:

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
method:

http://www.oreillynet.com/linux/blog/2006/05/restricting_rsync_over_ssh.html


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.