[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

'sudo' recommendations (fwd)




Does this (see bottom of forwarded messages) sound like a reasonable change to
make to the default debian install of sudo?

Should a bug report be filed?


Chris


----- Forwarded message from Brian Martin <bmartin@REPSEC.COM> -----

Date: 	Wed, 18 Nov 1998 16:47:26 -0700
From: Brian Martin <bmartin@REPSEC.COM>
Subject:      'sudo' recommendations
To: BUGTRAQ@netspace.org

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.Miller@courtesan.com> (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.

----- End forwarded message -----

-- 

----------------------------------------------------------------------
REALITY.SYS corrupted: Reboot universe? (Y/N/Q)   ....Debian GNU/Linux
----------------------------------------------------------------------
Reply with subject 'request key' for PGP public key.  KeyID 0xA9E087D5

Attachment: pgp9DRETPjXgX.pgp
Description: PGP signature


Reply to: