Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root
twitter.comFrom the FreeBSD man for date
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.
Users on MacOS can change the time without root access.
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
From System Preferences you can indeed set the date back to 1970:$ date 010101011970 date: bind: Permission denied date: settimeofday (timeval): Operation not permitted [15:45:41][dazza@imac.internal:~]
but there is a little lock that you might need to unlock (with a user password).$ date Fri 2 Jan 1970 00:56:44 BST [00:56:44][dazza@imac.internal:~]This does seem like a security issue on OSX.
That little lock icon is the same as running sudo from the command line. If the user is listed as an Administrator, then they're also able to sudo.
Changing back 01/01/1970 via Date & Time preferences doesn't need authentication, but the exploit still didn't work, at least for me.
> Changing back 01/01/1970 via Date & Time preferences doesn't need authentication
This is not true but it can be confusing if you've authenticated at all recently due to a grace period like sudo's.
I've never unlocked that panel, and I've rebooted recently, and still didn't need authentication. Are you sure that's as right?
The authentication for changing things via the System Preferences system is independent of sudo and "sticks" across reboots.
Is your account an Administrator account? Normal users are just Standard accounts and not Administrators.
System time or what is displayed to the user? Because they are two different things on some systems.
But most of the time, someone using MacOS has physical access to the box. They can always just boot up as single user and BOOM root:
This is absolutely not true. You must be listed as an Administrator to change system time. If you're an Administrator, then your account is also included in the admin group which means you have full sudo access anyway.
As far as I tested in the Date and Time preference pane,... Users enabled as an Administrator, yes. Standard users, no.
`date` still behaves as one expects.
Would this work with an LD_PRELOAD of libfaketime?
Also this would open up an entire vector of arbitrary command execution attacks if it was allowed.env_reset If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables. Any variables in the caller's environment that match the env_keep and env_check lists are then added, followed by any variables present in the file specified by the env_file option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by root with the -V option. If the secure_path option is set, its value will be used for the PATH environment variable. This flag is on by default.Also, you can not use LD_PRELOAD on sudo itself, as it is disabled for setuid binaries.
CVE-2013-1775 [0] in case you're wondering.
[0]: http://www.openwall.com/lists/oss-security/2013/02/27/22
http://www.ubuntu.com/usn/usn-1754-1/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1775
From the openwall link: > The vulnerability does not permit a user to run commands other than those allowed by the sudoers policy.
TL;DR: users in /etc/sudoers can run code as root with sudo.
An evil person with e.g. a stolen SSH key can escalate privileges on a machine without needing the user's password. It's not simply about sudo working as designed, it allows bypassing sudo's user authentication entirely.
I can think of a handful of corporate machines (e.g. web servers) I've had pubkey access on where sudo allowed the real admin to gain root from the same account via sudo.
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.
You mean, all of the NTP servers the machine uses. NTP will detect and reject a single server reporting bad time (assuming you have at least 3 servers configured, which is the recommendation).
You'd also have to do this when the NTP daemon first starts up, as:
-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.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.
You're building up a great big chain of complicated requirements. You're quickly approaching the point where it's easier to steal the machine.
Can't the evil person with said access just wait until the person legitimately runs sudo? Today's exploit just allows the attack to happen more quickly, if the attacker happens to be able to change the time on the clock by a few billion seconds without escalated access.
Is 31 characters less worthy of a TL;DR?
I think that was a facetious remark, meaning "so in other words, if you have sudo access you can use 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)
http://thread.gmane.org/gmane.linux.network/260061
bad times :/
Actually it is already fixed in many distros. For example in Arch Linux it took a day to fix since the CVE request: https://bugs.archlinux.org/task/34005 http://seclists.org/oss-sec/2013/q1/420
On the other hand my system here still crashes if I type file:/// with one big letter.
Linux 3.3 came out 2012-03-18, that's just less than 12 months ago.
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?
It looks like you can run `sudo -k` without authenticating via password, so I guess you could use this to bypass the password requirement even if the user had not previously entered their password (provided that the account is capable of changing the system time).
It's certainly worth mentioning (and patching), but I wouldn't describe it as "and boom you're root".
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 with your UID you've probably already lost anyway.
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.
Interesting! Does sudo somehow get confused about checking for a password at all when the current date is the UNIX epoch?
I wonder, does this require the user to be listed in sudoers with any privileges or is it just straight to root?
This gives you only the privileges that a successful "sudo" would give you, and requires a previous successful "sudo". It's a nice hack, but hardly the end of the world.
It is, however, the beginning of the UNIX world
the user does have to be listed in sudoers.
there's no confusion with sudo, it's running as designed. It compares the current timestamp to the user timestamp to determine whether to ask for a password or not. The first flaw is in the date command allowing unprivileged users to set the time. The second is that the -K flag to sudo makes the -k flag obsolete, so the latter should be dropped.
I 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.
Actually I had to write a ntp spoofer for an university class. With arpspoof it is easy to manipulate all ntp traffic. At least ntpdate didn't complain when you sent it some years forward or backward.
ntpdate won't complain because it's entire purpose is to set the time on a system that isn't synchronized with the rest of the world. So it is expected that the clock may have drifted by a substantial amount, and it is only meant to be used occasionally. It is especially bad practice to run it from cron.
On the other hand, ntpd is a daemon that is meant to be run continuously. It will complain if lower-strata time servers start jumping around, and has a built-in mechanism for ignoring time servers that seem to be giving incorrect time (compared to both other servers and the system's own idea of the current time). Note that, if having accurate time is important, ntpd also supports using external reference clocks with a pulse-per second connected to, for example, a serial port.
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.
This isn't always true: it all depends on where you [the attacker] are. If you've done something like compromise part of a large organization's network, it's entirely plausible that you could spoof either their internal NTP server or time.apple.com but not both.
-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.It won't. An NTP client will refuse to update it's system clock back to Epoch. There's a threshold after which ntpdate will refuse to adjust the clock.
No, ntpd adjusts the skew, not the actual time. NTP is specifically designed to prevent time from going backwards because that can cause all sorts of problems with tons of software. It only slows down and speeds up the clock to keep it in sync.
Can someone explain this a little more?
http://www.openwall.com/lists/oss-security/2013/02/27/22
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.
From http://www.openwall.com/lists/oss-security/2013/02/27/22:
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:
toif (current_time - last_password_time > INTERVAL) require_password();if (last_password_time == 0 || current_time - last_password_time > INTERVAL) require_password();
"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.
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:
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
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:
http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_...
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.
Automatic time sync?
I set it to "manual" to change the date, and wouldn't it go back to 2013, anyway?
Why 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?
Previous discussion, with a better link than to a tweet: https://news.ycombinator.com/item?id=5299326
Doesn't look like a whole lot of discussion.
Well, ya. I should have said previous link.