Re: Fix for ssh-1.2.27 symlink/bind problem

From: Casper Dik (casperat_private)
Date: Fri Oct 29 1999 - 02:34:30 PDT

  • Next message: Flothow, Sebastian: "AW: Mac OS 9 Idle Lock Bug"

    >Markus Friedl:
    >> Since Solaris 2.3 allowed you to attach (e.g. with gdb) to a
    >> programm running with euid==youruid, Tatu dropped the uid-swapping
    >> code and made ssh fork into two processes.
    >...
    >> void temporarily_use_uid(uid_t uid)
    >> {
    >> #ifdef SAVED_IDS_WORK_WITH_SETEUID
    >>   saved_euid = geteuid();
    >>   if (seteuid(uid) == -1)
    >>     debug("seteuid %d: %.100s", (int)uid, strerror(errno));
    >> #else
    >
    >ssh starts up with the unprivileged real UID of the user; therefore
    >setting the effective UID also to that of the user makes the process
    >memory accessible for unprivileged access. This is how any reasonable
    >UNIX system works, not just Solaris.
    
    If a system uses saved uids, the saved uid will remain 0; in that
    case you can still gain back the root uid; systems with saved uids
    do (at least, should not) allow any memory access in that case.
    
    In Solaris, we've changed the code around a few times, and these
    days you cannot gain back control over the process even if your
    credentials are a superset of the process' credentials.  Once a process
    has been set-uid it has been marked "tainted" and it cannot be
    examined/attached to with a debugger nor will it core dump.
    
    The latest Solaris 7 patches add a "coreadm" command which allow the
    system administrator to obtain cores of such processes anyway.
    
    >However, no reasonable UNIX system should allow unprivileged users
    >to debug a process that runs with real UID == 0, even when the
    >effective UID is that of the user.  That is the point I have been
    >making repeatedly in this thread, and now I am tired of making it.
    
    
    Even if its only the saved uid, access to the process should be
    prohibited.
    
    Because of sloppy programming practices, left over "capabilities" (such
    as file descriptors, privileged sockets, cached "secret" data) can be
    available in processes that relinquish all privileges.  That's why
    we modified Solaris.  The change isn't restricted to set-uid processes;
    processes that start out as root and call set*uid or set*gid are also
    non-debuggable and can't core dump. (e.g., /bin/login when run from
    a root daemon)
    
    Casper
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:09:08 PDT