Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

From the FreeBSD man for date<p><pre><code> Only the superuser may set the date, and if the system securelevel (see securelevel(7)) is greater than 1, the time may not be changed by more than 1 second. </code></pre> EDIT: so you need to be root anyway or have root access to change the date.

CVE-2013-1775 [0] in case you're wondering.<p>[0]: <a href="http://www.openwall.com/lists/oss-security/2013/02/27/22" rel="nofollow">http://www.openwall.com/lists/oss-security/2013/02/27/22</a><p><a href="http://www.ubuntu.com/usn/usn-1754-1/" rel="nofollow">http://www.ubuntu.com/usn/usn-1754-1/</a> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1775" rel="nofollow">http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1775</a>

TL;DR: users in /etc/sudoers can run code as root with sudo.

I see your wonky authentication bypass and raise you a local privilege escalation that is 100% reliable on every distro that's shipped a 3.3-3.8 kernel (last 18 months or so)<p><a href="http://thread.gmane.org/gmane.linux.network/260061" rel="nofollow">http://thread.gmane.org/gmane.linux.network/260061</a><p>bad times :/

From the vulnerability announcement, it seems like this only allows a user to "set" NOPASSWD for that user's sudo regardless of what's in sudoers. It also doesn't seem to allow escalation beyond what's in sudoers. Am I missing something?

Interesting! Does sudo somehow get confused about checking for a password at all when the current date is the UNIX epoch?<p>I wonder, does this require the user to be listed in sudoers with any privileges or is it just straight to root?

I wonder if it would be possible to walk back the date using an ntp mitm attack.

Can someone explain this a little more?

"Set your clock to 01.01.1970" BOOM, you can't! "date: cannot set date: Operation not permitted"

It may be worth noting that local privilege escalation vulnerabilities have always been dime a dozen, this is just a more egregious one.<p>In your planning always keep in mind that anyone with shell-access to your server can become root in one way or another, if he really wants to. There is little "defense in depth" after that point.

After using sudo from the command line, just remember to run sudo -K (note the capital-K) and you should be protected. The -K removes the timestamp which makes it impossible to reset it to 1/1/70 with -k.

It 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:<p><a href="http://www.sudo.ws/sudo/alerts/epoch_ticket.html" rel="nofollow">http://www.sudo.ws/sudo/alerts/epoch_ticket.html</a>

I'm surprised an issue that high-level's been able to lurk around for so long.

Debian unstable got a fix for this last night:<p><a href="http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_1.8.5p2-1+nmu1/changelog" rel="nofollow">http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_...</a>

Tried it on Debian Mint and it doesn't work. I can't set my clock without sudo.

It doesn't work on Ubuntu, the clock gets reset back to 2010, for some reason.

Why does "sudo -k" still exist, when it has obvious risks and is superseded by "sudo -K".<p>Why does 'sudo -k' not check to see if a timestamp exists, and avoid creating one if it doesn't yet exist?

Previous discussion, with a better link than to a tweet: <a href="https://news.ycombinator.com/item?id=5299326" rel="nofollow">https://news.ycombinator.com/item?id=5299326</a>