[8601] in bugtraq
'sudo' recommendations
daemon@ATHENA.MIT.EDU (Brian Martin)
Wed Nov 18 19:37:01 1998
Date: Wed, 18 Nov 1998 16:47:26 -0700
Reply-To: Brian Martin <bmartin@REPSEC.COM>
From: Brian Martin <bmartin@REPSEC.COM>
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.
