Tried it on Debian Mint and it doesn't work. I can't set my clock without sudo.
Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
41–50 of 74 posts
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#42Earlier quoted context omitted.
How are they going to change the date without having a path to superuser access already?
They could potentially spoof the machine's NTP server.
The NTP config on the machine would have to allow automatic changes without regard to the skew. I don't believe that is a default (or typically desired) configuration.
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#43Why does "sudo -k" still exist, when it has obvious risks and is superseded by "sudo -K".
Why does 'sudo -k' not check to see if a timestamp exists, and avoid creating one if it doesn't yet exist?
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#44Earlier quoted context omitted.
It sounds like you're overlooking the fact that software could do this without your knowledge.
Software that can do this could also just wait for you to run a sudo command and then install a rootkit before the timeout is reached. Or it could keylog your password. On desktop machines getting root is almost useless, you have all the sensitive information on the user account. Unless the attacker wants to install a rootkit in the kernel or open raw sockets or stuff like that. But if they can run arbitrary code wit…
I suppose that's true, but ideally there should be no situation in which you give a program or script access to a terminal with sudo's timeout unreached. Compromising information not stored on the machine should ideally require root.
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#45Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#46Earlier quoted context omitted.
Are you sure? If it is it sounds like a possible security issue. Time is pretty sensitive as soon as certificates are involved. Many auth systems assume the clock is properly synchronized across the system. If that's true IMO that's the security issue, not the arguably strange behaviour of sudo in a situation that should never occur.
well from the terminal $ date 010101011970 date: bind: Permission denied date: settimeofday (timeval): Operation not permitted [15:45:41][dazza@imac.internal:~] From System Preferences you can indeed set the date back to 1970: $ date Fri 2 Jan 1970 00:56:44 BST [00:56:44][dazza@imac.internal:~] but there is a little lock that you might need to unlock (with a user password). This does seem like a security issue on OSX…
Changing back 01/01/1970 via Date & Time preferences doesn't need authentication, but the exploit still didn't work, at least for me.
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#47It works if you set your time through system preferences in OSX, Gnome and KDE on some distros. Changing it on those desktop guis does not require admin password. Also see:
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#48I'm surprised an issue that high-level's been able to lurk around for so long.
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#49It works if you set your time through system preferences in OSX, Gnome and KDE on some distros. Changing it on those desktop guis does not require admin password. Also see: http://www.sudo.ws/sudo/alerts/epoch_ticket.html
Also be sure to set the date including timezone offset.
On OSX run sudo -k, open date and time prefs. Set date to 1970-01-01 00:00:00 including timezone offset (+1 for CET) then run sudo su
Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
#50I wonder if it would be possible to walk back the date using an ntp mitm attack.
Very, very difficult, unless the host relies on a single timesource. Best and common practice is to use 3-4 sources from different organizations in the ISC pool. It also wouldn't surprise me if most implementations of ntpd would have further safeguards about going 40 years back in time; at the very least the skew factor would make the clock change take a longgggg time to happen. There are much easier attack vectors.
It doesn't matter how many time sources there are. If you're doing an MITM attack, it's just as easy to fake multiple sources as it is to fake one.