To: BugTraq Subject: 'sudo' recommendations Date: Wed Nov 18 1998 15:47:26 Author: Brian Martin Message-ID:
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 (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.