COMMAND

    sudo

SYSTEMS AFFECTED

    Systems using sudo

PROBLEM

    Brian Martin discovered what he thought to be a bug in the  'sudo'
    package. After further investigation and talk with Todd C.  Miller
    (the maintainer of 'sudo'), he was informed that it was not a bug,
    but  expected  behavior  under  a  default install. The reason for
    this  advisory  is  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.

    The problem discussed  here is also  an issue with  Kerberos.  Any
    potential  attacker  could  use  cached  Kerberos  tickets to gain
    access to  hosts, services,  or privileges.   To circumvent  this,
    kdestroy your Kerberos ticket or log in as a different user.

    Also, it has been confirmed  that the same problem exists  in NIS+
    environment.   Attacker  can  get  right  credentials by issuing a
    command under already  authenticated UID, because  all credentials
    (public and decryptded secret  keys) are cached by  keyserv daemon
    and "indexed" by  UID.  The  only way to  get rid of  those cached
    information is to run keylogout command.

SOLUTION

    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.  You  can also issue sudo -k to  delete
    the sudo ticket before running something potentially dangerous.