'sudo' recommendations

From: Brian Martin (bmartinat_private)
Date: Wed Nov 18 1998 - 15:47:26 PST

  • Next message: pedwardat_private: "Re: KDE Screensaver vulnerability"

    During a recent client assessment, I discovered what I thought to be a bug
    in the 'sudo' package. After further investigating and talking with Todd
    C. Miller <Todd.Millerat_private> (the maintainer of 'sudo'), I was
    informed that it was not a bug, but expected behavior under a default
    install. The reason for this post it to make sure everyone is aware of
    this behavior and of the potential security concerns involved, no matter
    how obscure or how hard to exploit.
    
    This was found to be true on basically all platforms.
    
    Under a default installation, there are two elements that create the
    potential problem:
    
    1) 'sudo' is designed to allow a user to execute a command under
       elevated (root) privilege. To do so, the user must type his/her
       password for authentication. To avoid repeated typing of the
       user password, 'sudo' generates a 5 minute cache. This allows
       the user to type in additional 'sudo' commands with the assumption
       that authentication has already been performed.
    
    2) If a user logs in, and then executes sudo on a TTY (ttya1 for example),
       then logs in again on another TTY (ttya2) and executes sudo again,
       there is no check to ensure that the password cache is applied to
       the first TTY (ttya1) only. Instead, the cache works for BOTH ttya1
       and ttya2. This creates a five minute window for a second user to
       'piggy-back' off the cache generated on the first TTY 'sudo'.
    
    The first argument against this being a problem is that if a user logs in
    with the password, they can simply use that to authenticate themselves to
    'sudo' as well. However, several scenarios exist that could allow an
    attacker to gain a shell with user priv's, without logging in. Some of
    them include:  Spawning shells via IRC scripts (BitchX), IRC bots
    (eggdrop), or via httpd (poorly coded CGI scripts) may allow the attacker
    to gain the shell. From there, with 'sudo' under a default installation,
    the attacker could then 'piggyback' off the password cache and gain
    unauthorized root access.
    
    Solution: Fortunately, Todd Miller has already addressed these issues in
    most distributions past and present:
    
    1) 'sudo' can be configured for an alternate timeout value.
    
       Suggestion:  Decrease the alternate timeout value to '1'
    
    2) 'sudo' has already been designed with tty-based tickets, and can be
       enabled with the USE_TTY_TICKETS option.
    
       Suggestion:  Enable this feature.
    
    It is recommended that both options be implemented to ensure the security
    of your machines.
    
    I'd like to thank Mr. Miller for maintaining the 'sudo' package, as well
    as having the foresight to address the potential security concerns as
    outlined above.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:23:52 PDT