Ubuntu

Users can change the clock without authenticating, allowing them to locally exploit sudo.

Reported by Mark Smith on 2013-08-31
298
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Unity
Undecided
Unassigned
cinnamon
New
Undecided
Unassigned
sudo
Unknown
Unknown
policykit-desktop-privileges (Ubuntu)
Undecided
Unassigned
sudo (Ubuntu)
Undecided
Unassigned

Bug Description

Under unity and cinnamon, it is possible for a user to turn off network-syncronized time and then change the time on the system. It is also possible to "cat /var/log/auth.log" and find the last time a user authenticated with sudo, along with which pty they used. If a user had used a terminal and successfully authenticated with sudo anytime in the past, and left the sudo file in "/var/lib/sudo/<username>/", a malicious user could walk up to an unlocked, logged in machine and gain sudo without knowing the password for the computer.

To do this, a user would only need to launch a few terminals, figure out which pty they were on via "tty", find the an instance in /var/log/auth.log where sudo was used on that PTY, and set the clock to that time. Once this is done, they can run (for example) "sudo -s" and have a full access terminal.

1) This has been observed on Ubuntu 13.04, and may work on other versions.
2) This may have an effect on various window managers, but I confirmed it on Unity and Cinnamon
3) I expected to have to authenticate when I changed the time and date, as I do on Gnome and KDE. I also expected to be denied permission to auth.log
4) I was able to change the system time to whatever I wanted, and view auth.log. This was sufficient to access sudo without having to type my password.

Note: This bug also affects any version of OS X, though the mechanism is different. Some versions don't require you to authenticate to change the time through the GUI, but some do. No version I've seen requires authentication to use the "systemsetup" command, which can alter the time from the command line. This may be an overall bug in sudo. Why can I bypass security by changing the time?!

Mark Smith (tntc-tig) wrote :

Forgot to mention, I submitted the bug to Apple re: OS X as well.

Stephen M. Webb (bregma) wrote :

If the problem is that the Gnome Control Center allows the time to be changed without authentication, then the problem is in the Gnome Control Center.

affects: ubuntu → gnome-control-center (Ubuntu)
Mark Smith (tntc-tig) wrote :

Kubuntu-desktop has the same problem, and gnome3 on Debian does not. I suspect it has to do with the way ubuntu variants grant privs to the desktop environment across the board. On another, stranger note: A bunch of the files in /var/lib/sudo/ suddenly had timestamps of 1/1/1985 05:00:00. I subsequently set my system time to that date, and could again escalate on some ptys/ttys without a password. I never set my system date to 1985 before that point. It looks like it's something weird something else in the system is doing. See http://superuser.com/questions/297566/sudo-keeps-asking-me-for-my-password-in-fish-shell for something similar. Look! His timestamps are in 1985 too!

Mark Smith (tntc-tig) wrote :

I can't edit comments for some reason, so allow me to revise the first line in comment 3:
Kubuntu-Desktop and ubuntu-gnome-desktop (Gnome3) have the same problem. Debian's date/time panel in gnome3 requires authentication. It seems that ubuntu variants allow regular users to edit the system date/time across the board.

Marc Deslauriers (mdeslaur) wrote :

This is by design. The policykit-desktop-privileges package contains a policykit file that allows administrative users to do so:

from /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla:

[Setting the clock]
Identity=unix-group:admin;unix-group:sudo
Action=org.gnome.clockapplet.mechanism.*;org.gnome.controlcenter.datetime.config
ure;org.kde.kcontrol.kcmclock.save
ResultActive=yes

information type: Private Security → Public
Changed in unity:
status: New → Invalid
Changed in gnome-control-center (Ubuntu):
status: New → Invalid
Mark Smith (tntc-tig) wrote :

This is by DESIGN?
Your design is that any user can change the time, and therefore bypass the security of sudo?
What's the justification for not having the user enter a password to change the time? Convenience?

Marc, with all due respect, did you even read the bug?

"If you disable the sudo password for your account, you will seriously compromise the security of your computer. Anyone sitting at your unattended, logged in account will have complete Root access, and remote exploits become much easier for malicious crackers."

This policy kit change adds a single condition: That the user has used sudo to escalate at some point, and it creates /exactly/ the same conditions.

I'm going to re-open this just to be sure. It seems incredible that Ubuntu would intentionally let people bypass security like that.

Mark Smith (tntc-tig) wrote :

Are you really sure users are supposed to be able to bypass sudo like that?

Changed in gnome-control-center (Ubuntu):
status: Invalid → New
Tim Ingalls (iam-s) wrote :

As a person working in a secure facility with quite a few machines running Ubuntu, this is a major security issue. This is a flaw that allows root access without a password. The fact that this issue is being brushed off is angering, but even worse is that it's been made public. I shouldn't even be able to know about an issue like this until it has been fixed already. This issue needs to be taken seriously, and fixed, as soon as possible.

Mark Smith (tntc-tig) on 2013-09-04
information type: Public → Public Security
Marc Deslauriers (mdeslaur) wrote :

Only administrators can change the local time without authenticating. Regular non-administrative users cannot. This allows administrative users travelling with laptops to change the timezone without getting an authentication prompt.

Your attack vector assumes that an administrative user is going to leave an open session unattended. If that is the case, there are a whole slew of attacks that are possible, and don't require changing the date. For example, creating scripts in ~/bin that are higher in the path then system binaries.

If you have administrative users that are leaving session unlocked, you have a more serious security issue than being able to change the time.

Since your local security policy is different than what is shipped in a general purpose operating system, I suggest:

1- Requiring your administrative users to lock their workstation when they are left unattended.
2- Requiring your administrative users to use "sudo -k" to forcibly invalidate cached credentials.
3- Removing the policykit-desktop-privileges package, or overriding the policy with a local one.
4- Disabling ntp, or setting up ntp authentication.
5- Setting a firmware password on local machines.

Changed in gnome-control-center (Ubuntu):
status: New → Opinion
Mark Smith (tntc-tig) wrote :
Download full text (3.2 KiB)

>This allows administrative users travelling with laptops to change the timezone without getting an authentication prompt.

Why is saving the traveling admin from typing their password a couple of times a day worth compromising security for everyone else? No, seriously. Why?

>Your attack vector assumes that an administrative user is going to leave an open session unattended.

Yes, my assumption is that users will forget to lock their machines, because it happens all the time. This is especially true if it's a personal machine, and they are the ONLY user.

>If that is the case, there are a whole slew of attacks that are possible, and don't require changing the date. For example, creating scripts in ~/bin that are higher in the path then system binaries.

Even if that number is high, that's no excuse. Is your stance really "Well, they could compromise security 100 ways, so what's one more?" Plus, how many of those attacks require 0 external resources, and creating 0 additional files on the system, and would leave little trace beyond a hiccup in the time/date?

>Since your local security policy is different than what is shipped in a general purpose operating system...

Wanting a slightly more secure system is more of an edge case than changing the time zone repeatedly? REALLY?
Does Windows 8 count as general purpose to you? It requires escalation to change the date and time. Maybe their escalation system isn't very good, but it's still better than blithely letting admins change the system time without so much as a prompt. Also, their security system doesn't rely on file timestamps, so it's less likely to grant someone root access.

> 1- Requiring your administrative users to lock their workstation when they are left unattended.

People make mistakes. Are you telling me you've NEVER forgotten to lock your workstation? You've NEVER seen another admin forget to lock theirs?

> 2- Requiring your administrative users to use "sudo -k" to forcibly invalidate cached credentials.

That only works on a per pty/tty basis on ubuntu. It only "invalidates" one of the sessions, and it "invalidates" it by changing the timestamp to a date to Dec. 31, 1969 or Jan. 1, 1970. You could try "sudo -K", which deletes the file, but again only on a per pty/tty basis.

> 3- Removing the policykit-desktop-privileges package, or overriding the policy with a local one.

Oh good, more administrative work, all to save typing a password! Pity about all the users who don't know what policykit-desktop-privileges is or does though...

> 4- Disabling ntp, or setting up ntp authentication.

Disabling ntp wouldn't help, since the whole point is that the user can change the time to anything manually anyhow.

> 5- Setting a firmware password on local machines.

This doesn't help if they walked away and forgot to lock their machines.

I especially love how #2 requires the user to remember to execute a command before they close their terminal, and adds an extra 7 keystrokes PER TTY/PTY. All this to save a hypothetical traveling admin from having to type his password once when he moves to a different timezone. If they want to save themselves a few keystrokes to change the ti...

Read more...

Mark Smith (tntc-tig) wrote :

A somewhat sensible workaround I can find at the moment is to force re-authentication every time you type sudo. The way to do this is by adding:

Defaults timestamp_timeout=0

to the Defaults section of your /etc/sudoers

This will work on Ubuntu, OS X, and other variants.

Details can be found in http://www.sudo.ws/sudoers.man.html

We really shouldn't be trusting the clock to being with. The fact that Ubuntu developers have seen fit to add "convenience features" to bypass security rather proves the point.

Download full text (5.3 KiB)

On 13-09-04 10:19 AM, Mark Smith wrote:
>> This allows administrative users travelling with laptops to change the
> timezone without getting an authentication prompt.
>
> Why is saving the traveling admin from typing their password a couple of
> times a day worth compromising security for everyone else? No,
> seriously. Why?

It only compromises security for people who use sudo on their workstation, and
don't add the -k flag to the command line when they do. I suspect there are more
users who travel with their laptops than there are people who use sudo on them.

>
>
>> Your attack vector assumes that an administrative user is going to leave an open session unattended.
>
> Yes, my assumption is that users will forget to lock their machines,
> because it happens all the time. This is especially true if it's a
> personal machine, and they are the ONLY user.

If you can't rely on admins to properly lock their session, you can't rely on
them to not leave a console open with sudo rights either. At some point a
minimum is required. Locking their console, or using sudo with -k is the minimum.

>
>
>> If that is the case, there are a whole slew of attacks that are possible, and don't require changing the date. For example, creating scripts in ~/bin that are higher in the path then system binaries.
>
> Even if that number is high, that's no excuse. Is your stance really
> "Well, they could compromise security 100 ways, so what's one more?"
> Plus, how many of those attacks require 0 external resources, and
> creating 0 additional files on the system, and would leave little trace
> beyond a hiccup in the time/date?

I'm saying preventing the admin user from modifying the system clock is security
theatre if the system is configured to use ntp, or doesn't prevent access to
changing the clock in the system firmware. Even if the admin user needs a
password to change the clock, anyone can step up to the workstation and plug in
a network cable to a fake ntp server.

If you want to be able to trust the system time, you need to harden a lot more
than simply requiring a password prompt.

>
>
>> Since your local security policy is different than what is shipped in a general purpose operating system...
>
> Wanting a slightly more secure system is more of an edge case than changing the time zone repeatedly? REALLY?
> Does Windows 8 count as general purpose to you? It requires escalation to change the date and time. Maybe their escalation system isn't very good, but it's still better than blithely letting admins change the system time without so much as a prompt. Also, their security system doesn't rely on file timestamps, so it's less likely to grant someone root access.

There's a fine balance between security and usability, and not everyone is
comfortable with the same level of security. As I've mentioned before, it is
trivial to modify the defaults to achieve the level of security that is
appropriate for your environment.

>
>
>> 1- Requiring your administrative users to lock their workstation when they are left unattended.
>
> People make mistakes. Are you telling me you've NEVER forgotten to lock
> your workstation? You've NEVER seen another adm...

Read more...

Mark Smith (tntc-tig) wrote :

> There's a fine balance between security and usability, and not everyone is
comfortable with the same level of security. As I've mentioned before, it is
trivial to modify the defaults to achieve the level of security that is
appropriate for your environment.

If that's the case, why are you defaulting to a level that Debian, Fedora, Mint, and Windows all feel is too lax? Why not let the very few users who need this, change it to be less secure?

Based on my discussions, it seems that this is actually a *sudo* bug, since it uses the non-monotonic clock, rather than using other system features.

Marc Deslauriers (mdeslaur) wrote :

> If that's the case, why are you defaulting to a level that Debian, Fedora, Mint, and Windows all feel is too lax? Why not let the very few users who need this, change it to be less secure?

Because those desktop environments don't provide automatic geoip-based timezone updating.

Mark Smith (tntc-tig) on 2013-09-08
Changed in sudo:
importance: Undecided → Unknown
status: New → Unknown

GNOME 3.10 will indeed allow local admins (not standard users) to change time settings without typing a password.

It also introduces automatic geolocation-based timezone updating. :)

Mark Smith (tntc-tig) wrote :

Michael:
But again, this totally ignores the question: Why on earth do we need that? How many times per day are you changing your clock that this is necessary?!

Mark Smith (tntc-tig) wrote :

Todd C Miller is working on it from the sudo side upstream, potentially using CLOCK_MONOTONIC.

Marc Deslauriers (mdeslaur) wrote :

oh, that would be great!

Matthias Niess (mniess) wrote :

I still get the feeling that you don't see the seriousness of this bug. Any drive-by browser-exploit can now escalate to root privileges because of this. Most Ubuntu users are running it with their admin account (that has sudo privileges). Running the wrong script or visiting the wrong website will be enough.

Matthias Niess (mniess) wrote :

To clarify: an exploit could run code in a terminal, get the TTY of that terminal and search auth.log for that TTY to change the time, right?

Mark Smith (tntc-tig) wrote :

It's a bit more complicated than that, but not much: Sudo stores the SID in the authentication file. However, setsid is installed by default, so you can just launch processes with new SIDs until you get a match. You can either run setsid and sudo a bunch and hope that you match up, or you can look up the SID (also found in auth.log) and match that without running sudo. It's not trivial, but it's certainly doable.

Marc Deslauriers (mdeslaur) wrote :

Perhaps we could also investigate a way for gnome-control-center's timedated to invalidate sudo authentication files when the system date is changed.

Eero (eero+launchpad) wrote :

One more thing I noticed while checking what's going on with sudo. To my understanding newer versions of sudo treat the epoch as a special case and ignore it as an invalid date. So why does Ubuntu's /etc/init.d/sudo set sudoers timestamps to 198501010000 during the boot? Shouldn't they be set to epoch to invalidate them?

Marc Deslauriers (mdeslaur) wrote :

@Eero: yes, I noticed that while investigating last night also. I'll file a bug, and a bug with Debian.

Changed in sudo (Ubuntu):
status: New → Confirmed
Marc Deslauriers (mdeslaur) wrote :

@Eero: I've filed bug 1223297 in Ubuntu, 722335 in debian.

Jeremy Bicha (jbicha) on 2013-09-12
affects: gnome-control-center (Ubuntu) → policykit-desktop-privileges (Ubuntu)
Mark Smith (tntc-tig) wrote :

There is now a beta version of sudo (1.8.10b1) that has the timestamp changed to use the monotonic clock. I continue to suggest that the setting to require no password to change the clock be opt-IN rather than opt-out.

Mark Smith (tntc-tig) wrote :

There is now a full release of sudo 1.8.10, which works around the security flaw introduced by policykit-desktop-privileges (Ubuntu). I strongly suggest packaging and releasing this update ASAP.

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

Other bug subscribers

Remote bug watches

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