Bug 357 - Persisting authorisation between programs that access sudo after password has been entered
Persisting authorisation between programs that access sudo after password has...
Status: RESOLVED FIXED
Product: Sudo
Classification: Unclassified
Component: Sudo
1.6.9
IBM Linux
: normal security
Assigned To: Todd C. Miller
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-06 22:33 MDT by Michael
Modified: 2010-06-18 15:47 MDT (History)
0 users

See Also:


Attachments
example code (717 bytes, text/plain)
2009-06-06 22:33 MDT, Michael
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael 2009-06-06 22:33:12 MDT
Created attachment 256 [details]
example code

Program Languages tested: Python, Perl

If program A requires the user to enter their sudo password that access will be available to program B for as long as the password authorisation is valid. 
Timeout still happens, though it appears that any subsequent call actually resets the timer so that the timeout is delayed, though I can't really confirm this.

Also (only tested in python):
Calls to sudo -k will not work if the call to the sudo command that required the password had a Stdin set, and the call to the sudo -k does not have it set, the call is effectively ignored.

The only way I think this could be exploited would be to wait for programs that do not explicitly revoke the password authorisation and then execute after them so gaining full sudo access. A timeout of 0 would obviously negate this possibility.
Comment 1 Todd C. Miller 2009-07-28 14:17:50 MDT
It is normal for sudo to update the timestamp file when a command is run.  It looks like you have per-tty timespamps in effect in /etc/sudoers.  In your first example, sudo is able to determine the tty for the "sudo -k" because stdout still references the tty you are logged in on.  The subsequent command, however, has both stdin and stdout redirected to a pipe so there is no way for sudo to determine the tty.  In this case, sudo uses the string "unknown" for the timestamp file (since the tty is not discernable).  So, while you did reset the sudo timestamp for your tty, the actual command you ran via sudo used a different timestamp file which had not been reset.

In the second example, both sudo command used the same timestamp file so the behavior is consistent.

This is a drawback of per-tty timestamps.  I've considered changing the meaning of -K to remove all timestamps when the tty_timestamps option is in effect.

Another option would be to always prompt for a password if per-tty timestamps are in use and sudo is unable to determine the tty.
Comment 2 Todd C. Miller 2010-06-18 15:47:33 MDT
In sudo 1.7.3 (due at the end of the month), sudo will always prompt for a password if tty tickets are enabled and sudo is unable to determine the tty.