sudo: timestamp too far in the future

Bug #76639 reported by Mark Reitblatt
266
Affects Status Importance Assigned to Milestone
sudo (Ubuntu)
New
Medium
Unassigned

Bug Description

Binary package hint: sudo

I ran sudo iwlist eth1 scan about 20 times over a minute, then connected to a wireless network through network manager. When I tried to use sudo immediately after that, I got this error:

sudo: timestamp too far in the future: Dec 20 14:44:38 2006

The current time is Dec 20 13:55:37 CST 2006, and I haven't been messing with the date or time.

This is on Dapper.

Changed in sudo:
importance: Undecided → Medium
Revision history for this message
iKs (iks279) wrote :

If you reboot fsck will fix it.

Anyway I did have this bug too once...

Revision history for this message
Mark Reitblatt (mark-reitblatt) wrote :

If you wait a little while and get closer to the timestamp, sudo starts working, but with no password needed. I'm adding a security vulnerability as this is unexpected behavior of a part of the security subsystem.

Revision history for this message
jcfp (jcfp) wrote :

Sounds like connecting to the network ran ntp via /etc/network/if-up.d/ntpdate, causing time to be synced and set an hour or so back (check logs?). Which would in turn be reason for sudo to complain about timestamps being too far in the future.

Man page only specifies "Timestamps with a date greater than current_time + 2 * TIMEOUT will be ignored and sudo will log and complain. This is done to keep a user from creating his/her own timestamp with a bogus date on systems that allow users to give away files".

Apparently the timestamp is only ignored for as long as it's too far off, but not removed or invalidated. With timeout at (iirc) 15 minutes, it would take about 19 minutes in your situation for sudo to "start working again" without new password.

Revision history for this message
Mark Reitblatt (mark-reitblatt) wrote :

Only thing is, I don't have my system setup to use NTP. But, this interesting bit showed up in the logs:

Dec 20 13:44:59 localhost ntpdate[15309]: step time server 82.211.81.145 offset -3598.328095 sec
Dec 20 13:47:06 localhost ntpdate[15446]: step time server 82.211.81.145 offset 0.000087 sec
Dec 20 14:18:09 localhost ntpdate[16404]: step time server 82.211.81.145 offset -3598.302093 sec

Revision history for this message
Mark Reitblatt (mark-reitblatt) wrote :

Looks like this is something odd that happened with ntpdate, not sudo.

Changed in sudo:
status: Unconfirmed → Rejected
Revision history for this message
jens_acamedia (commercial-acamedia) wrote :

im opening again since im experiencing this on feisty and believe it to be a bug.

if you manually change the time to a few hours earlier after having used sudo you will now be unable to run any system preferences tools.

since they use gksudo e.g. network-admin will quit quietly. even if it "only" takes 15 minutes this behaviour seems very confusing to a user who cant do any config for this length of time...i think this might be a bug in sudo...

my error is also

sudo: timestamp too far in the future: Mar 28 12:44:36 2007
jens@bigboy:~$

Changed in sudo:
status: Rejected → Unconfirmed
Revision history for this message
Brett Alton (brett-alton-deactivatedaccount) wrote :

I can reproduce this on my 6.06.1 LTS LAMP server:

$ sudo vi /etc/network/interfaces
 *I changed the IP from DHCP and added in my address, gateway and subnet
$ sudo /etc/init.d/networking restart
 *Applied the changes
$ sudo vi /etc/hosts
sudo: timestamp too far in the future: Apr 21 13:07:27 2007
 *current time is 09:30:00 EST

Revision history for this message
toycat (toycat) wrote :

I think the problem may be related with DST (Daylight Saving Time). I think, that when editing file with vi and saving it, the DST is somehow misinterpreted and the timestamps are set to +1 hour incorrectly, which causes the sudo error. Just a thought, but I had no problems with sudo before editing the file as brettalton said. Hope this will be fixed soon.

Revision history for this message
Steve Alexander (stevea) wrote :

I saw the same issue on gutsy just now. I tried telling the date and time applet to synchronize with internet servers. It couldn't find the ntp package, but nonetheless seemed to be able to do an ntpdate call.

After, I tried to run apt-get update with sudo, and sudo would not run, giving me the "timestamp too far in the future" error.

So, I was stuck, unable to change the time, as that would require running sudo also.

Revision history for this message
martalli (drsiegfried) wrote :

Incidentally, I just had this same problem with my old pentium II. It's a headless server that primarily runs mpd for our music on hold. I logged in through ssh and changed the network so that I could run apt-get for updates after changing the network structure at the office. I had no problems until the network successfully connected to the internet. Then, I was getting the "sudo timestamp to far in the future..." error.

From an ssh terminal on a headless server I could not change the time without running ssh. I threw up my hands and went to do something else. I cam back an hour or two later and voila, it worked fine. Something happened within that time to resolve the error, and I wonder if it wasn't just a ntpdate update or something like that.

Revision history for this message
ash_comp (ashish-comp-pune) wrote :

yes, I am also getting the same error. I thnk it has to be a bug or a security measure. I changed my network several times and also used ssh several times. Once I typed "sdo" instead of "sudo" for ssh. And after that it starts giving me message for all sudoers commands.

 sudo: timestamp too far in the future: Dec 12 13:16:01 2007

I think it happened under same circumstances for most of people. So it might be some security issue over network or a bug.
I am using ultimate ubuntu based on feisty7.04

it get solved using
     sudo -K
no need to restart the machine or to remove any directory. but I think it removes some commands from history.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.