When a user successfully authenticates with sudo, a time stamp file is updated to allow that user to continue running sudo without requiring a password for a preset time period (five minutes by default). The user's time stamp file can be reset using "sudo -k" or removed altogether via "sudo -K".
A user who has sudo access and is able to control the local clock (common in desktop environments) can run a command via sudo without authenticating as long as they have previously authenticated themselves at least once by running "sudo -k" and then setting the clock to the epoch (1970-01-01 01:00:00).
The vulnerability does not permit a user to run commands other than those allowed by the sudoers policy.
By default, sudo displays a lecture when the user's time stamp
file is not present. In sudo 1.6, the -k option was changed
to reset the time stamp file to the epoch rather than remove
it to prevent the lecture from being displayed the next time
sudo was run. No special case was added for handling a time
stamp file set to the epoch since the clock should never
legitimately be set to that value.
when you run sudo, it might ask for a password. if you enter the right password, it sets a user timestamp saying "this was when you last entered your password", and for some (configured) amount of time after that, you can run sudo without requiring a password.
sudo -k sets the timestamp to the epoch under the (misguided) assumption that the epoch will always be older than the configured time interval.
some distributions allow any user to change the system time without requiring root privileges. These are typically user-friendly, single-user distributions, but many people run these same distributions on multi-user server boxes as well.
so, if an attacker gains access to a user account, and assuming that user does have the right to sudo to root, the attacker can run these three commands to gain a root shell.
sudo -k resets the "needs a password to be entered" flag by changing the last-password-entered time to appear to be the UNIX epoch (time 0).
If you then change the date to be the same day (which can be done without root permissions in modern Linux distros by using polkit or similar things), then you can use sudo to run commands as root without a password.
Presumably, sudo checks the 'last-successful-login' entry alone before deciding whether to require a password. It ends up thinking you've previously successfully logged in even if you've never actually typed in the needed password.
So there are two ways I can see to fix this. Either make setting the time always requires a password, or, add a signal that time-sensitive processes can listen to that gets tripped whenever time is altered.
There's a much simpler fix that is local to sudo. Sudo has to make the decision of whether to require a password. Just change the line that says something like:
if (current_time - last_password_time > INTERVAL) require_password();
