rssh: pizzacode security alert

From: Derek Martin (code_at_pizzashack.org)
Date: 10/23/04

  • Next message: Michal Zalewski: "Update: Web browsers - a mini-farce (MSIE gives in)" 
    Date: Sat, 23 Oct 2004 17:48:29 +0900
To: rssh-discuss@lists.sourceforge.net

    PIZZACODE SECURITY ALERT

    program: rssh
    risk: low[*]
    problem: string format vulnerability in log.c
    details:

    rssh is a restricted shell for use with OpenSSH, allowing only scp
    and/or sftp. For example, if you have a server which you only want to
    allow users to copy files off of via scp, without providing shell
    access, you can use rssh to do that. Additioanlly, running rsync,
    rdist, and cvs are supported, and access can be configured on a
    per-user basis using a simple text-based configuration file. The rssh
    homepage is here:

      http://www.pizzashack.org/rssh/

    Florian Schilhabel has identified a format string bug which can allow
    an attacker to run arbitrary code from an account configured to use
    rssh. [*]In general the risk is low, as in most cases the user can
    only compromise their own account. The risk is mittigated by the fact
    that before this bug can be exploited, the user must log in
    successfully through ssh. This means that either the user is known to
    the system (and therefore the administrators), or that the system is
    probably already compromised.

    However, on some older systems with broken implementations of the
    setuid() family of functions, a root compromise may be possible with
    certain configurations of rssh. Specifically, if rssh is configured
    to use a chroot jail, it will exec() rssh_chroot_helper, which must be
    setuid root in order to call chroot(). Normally, rssh_chroot_helper
    calls setuid(getuid()) and drops privileges before any of the logging
    functions are called, making a root compromise impossible on most
    systems. However, some older systems which handle saved UIDs
    improperly may be vulnerable to a root compromise. Linux in
    particular is not vulnerable to this, nor should modern
    POSIX-compliant Unix variants be. POSIX defines that the setuid()
    system call will set all UIDs (UID, saved UID, and effective UID) the
    specified UID if it is called with root privileges. Therefore in
    general, a root compromise is not possible, and I am not specifically
    aware of any systems on which one is possible.

    The 2.2.2 release of rssh fixes this string format vulnerability. I
    have also gone over the code to make sure that no other such
    vulnerabilities exist. In addition to fixing this problem, rssh
    contains some new code to help identify certain problems for debugging
    problems when rssh fails. Additional logging of error conditions is
    performed. 

    -- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

  • Next message: Michal Zalewski: "Update: Web browsers - a mini-farce (MSIE gives in)"