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

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

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.

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!

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.

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

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.

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

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.

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.

>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...

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.

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...

> 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.

> 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.

Looks like upstream GNOME is now also allowing this too, so presumably the other distros will have a similar policy:

https://git.gnome.org/browse/gnome-control-center/commit/panels/common/gnome-control-center.rules?id=88eeb8cb2d28d75610b1fa39839e69388ceb4eca

https://bugzilla.gnome.org/show_bug.cgi?id=646185

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. :)

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?!

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

oh, that would be great!

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.

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?

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.

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

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?

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

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

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.

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.

Congratulations, Ubuntu team. You have now fallen behind *Debian's Stable Release* in a security update to sudo, despite several releases in between. They even released their newest (24 month development cycle) in the same month as you. This has been fixed, *fully fixed*, for over a year now. Epic fail.

mscs@water:~$ sudo -V
Sudo version 1.8.10p3
Sudoers policy plugin version 1.8.10p3
Sudoers file grammar version 43
Sudoers I/O plugin version 1.8.10p3
mscs@water:~$

https://packages.debian.org/search?keywords=sudo
https://launchpad.net/ubuntu/+source/sudo

Just to be clear, you can't currently bypass security by simply changing the time, you also have to guess the tty, and create a new one with the exact timestamp and inode. That information is in a timestamp file you can't access.

While adding the monotonic clock is an incremental improvement, it's not a critical issue.

Really? If the terminal I last ran sudo in is open still on the machine, and it's unlocked, I couldn't simply change the time back to the previous sudo command an escalate?

Even if it's a remote chance, it's still an easy exploit.

/var/log/auth.log is certainly readable by a program that uses a different exploit to gain access to that admin user (say, a browser exploit) and contains the PTY and timestamp. It doesn't even have to be exact: It just has to be ~ 15 minutes after the last sudo, right?

This is a simple upgrade that even your parent distribution has adopted for their stable. Why ignore it for over a year? Can you please show me the information about the inode? My impression was that it was based on the SID, rather than inode, but perhaps that has changed.

/*
 * Info stored in tty ticket from stat(2) to help with tty matching.
 */
static struct tty_info {
    dev_t dev; /* ID of device tty resides on */
    dev_t rdev; /* tty device ID */
    ino_t ino; /* tty inode number */
    struct timeval ctime; /* tty inode change time */
} tty_info;

That is the info required.
Yes, if you leave your terminal open, the pty is still there.

Debian hasn't fixed this in squeeze or wheezy yet, it's fixed in jessie because they have a recent enough version of sudo.

We do plan on backporting monolithic timer support, we just have not had time yet.

> Debian hasn't fixed this in squeeze or wheezy yet, it's fixed in jessie because they have a recent enough version of sudo.

They haven't fixed it because they were never vulnerable: they don't allow you to change the clock without a password.

> We do plan on backporting monolithic timer support, we just have not had time yet.

Was a year and two releases not enough time?

Hi Mark - I've taken a look at the details in this bug, the upstream sudo bug, the /r/linux thread, and the upstream sudo fix. I appreciate and respect your thoroughness.

After taking all of the details into account, I consider this issue to be low severity due to the mitigating factors involved. Specifically, I don't see a way for an attacker, without physical access, to use an arbitrary code execution vulnerability in combination with the issue that you've described in this bug to elevate his/her privileges. Considering this, the attack requires an admin user leave his/her desktop session unlocked and for an attacker to come across this unlocked desktop session. Since there are many different ways to attack an unlocked desktop session, best security practices dictate all users lock their screens when not at their computer.

We will fix this issue in the next Ubuntu release (15.10) by including sudo 1.8.10 or newer. Due to the issue’s low severity and considering our practice of prioritizing resources on publishing security updates that fix issues of greater security impact, we may fix this issue in stable releases of Ubuntu in the future if another sudo vulnerability of higher severity is found or if new details emerge regarding this issue.

Tyler,
it's great that this bug will be fixed. However, I have some concerns about the mitigations factors.

1) Timestamp: Easily found in the auth.log, and easily bypassed due to an unlocked clock.

2) TTY: The tty of the first gnome-terminal running is (as far as I can tell) /dev/pts/0. That's predictable, so if the auth.log contains a sudo session on /dev/pty/0, it's trivial to re-create the tty.

3) inode: Does this mean Session ID? If so, I'm worried. If not, we have a bigger problem. Here's why:

hexdump -d /var/lib/sudo/mscs/0
0000000 00013 00000 00000 00000 34816 00000 00000 00000
0000010 00003 00000 00000 00000 01000 00000 00005 00000
0000020 31291 00000 00000 00000
0000028

hexdump -d /var/lib/sudo/mscs/0
0000000 00013 00000 00000 00000 34816 00000 00000 00000
0000010 00003 00000 00000 00000 01000 00000 00005 00000
0000020 01464 00000 00000 00000
0000028

See 31291, and 01464 in the second column near the bottom? It turns out that they correspond to SID.
I checked using python:

import os
pid = os.getpid()
sid = os.getsid(pid)
print pid, sid

1775 1464

I tested this several times. Since the setsid can generate a new sid, and there are only 32768 possible SIDs as configured out of the box, how hard would it be to brute force the sid, simply running sudo -n -s? If SID isn't == to Inode, where's inode in that file? The ls -i command reports no difference in the inode of the file itself (545179 both times, even if the gnome-terminal is closed and re-opened.)

I've poked at the sid option already, and have indeed had good success with getting sessions matching the sid using this brute force method. It's now a question of how I get that session lined up with the pty (which is predictable) and see if sudo -s works without a password at the last escalation time. Perhaps there is some other security feature that will block me, but right now I don't see it.

Thoughts?

Hi Mark,

In your first hexdump, this is what those values represent:

00013 = id of the device the tty is on
34816 = device id of the tty file
00003 = inode of the tty file
01000 = uid of the tty file
00005 = gid of the tty file
31291 = sid

The id of the device the tty is on is known. So is the uid and gid.
The device id of the tty file can be found in auth.log.

So that leaves the inode of the tty file and the sid.

You need to be able to open a new tty and hit the same tty number, the same sid and the same inode, and you need to do it blindly without knowing in advance what the inode and the sid were.

Notice that only the SID changed though. That gives me a 1 in 32k chance, and I can generate them basically at will with setsid. In my testing so far, the inode of the TTY file for /dev/pts/0 has stayed "3" across several reboots. If it doesn't change, then it is moot from a security standpoint.

To clarify: I reboot, log in, open gnome-terminal. The tty is always /dev/pts/0, and ls -i /dev/pts/0 shows an inode of 3. This occurs even if I shut down and power back on, though admittedly in a VM.

Yes, the tty numbers and inodes reset when you reboot. That is why sudo has an init script that forcibly expires all the timestamp files when you reboot.

Without rebooting, the tty, inode, sid should change for every terminal you open.

You could probably write a script that attempts to brute force low-digit sids and inodes when you supply a tty number. That should be possible.

> Without rebooting, the tty, inode, sid should change for every terminal you open.

When I tried this on 15.04, the tty and inode didnt: only the SID changed. Closing a gnome-terminal and reopening it got the same tty and SID. For *additional* terminals, they got new ttys and inodes, but if you close the one on /dev/pty/0 the file will dissapear. The next gnome-terminal you launch will be on /dev/pty/0 with the same inode as the old one you closed. Can you confirm?

Apologies for any typos, I'm on my phone.

Yes, there's a chance the same tty can get reused with the same inode if nothing else requires a tty in the meantime.

So it's simply a matter of opening a bunch of terminals to get the same tty and rolling the sid in each of them.

Yup, I think so. while true; do setsid <something to run sudo>; done; or the like. In my tests rolling through then all took about 5 minutes, and that was in a crappy VM with 1 core and 30% CPU being used by compiz. I haven't gotten it to pop an escalated shell yet, but I'll poke at it more tonight after work.

Should be pretty trivial, and slightly more amusing than simply trojaning ~/.bash* or ~/bin/sudo.

For completeness' sake, perhaps it could also do the same for the polkit timestamp files also.

Indeed. Trojaning those requires waiting for the user. Why lay a trap and wait when you can just break down the door? If I can use dogtail or similar to automate the clock and suddenly we're in drive-by territory.

You can set the time with:

timedatectl set-time "2000-01-01 10:00:00"

A solution could be setting one clock for users, which can be set to their prefered timezone and one for the system (root) which is used by cron jobs etc

Kay, the update to sudo (1.8.10) actually solves this by using the monotonic clock. All that needs to happen is for Ubuntu to udpate to it. :)

Oh, nevermind! You're talking about outside of the sudo instance. In the case of Cron, etc: just let *the user* decide whether they want to be asked after the first time. Make it an option to unlock the clock, disabled by default but still available.

Serious question: I understand that this is consider a low priority issue, but how hard is to update sudo? why can't it just be pushed with the next update?

> You can set the time with:

> timedatectl set-time "2000-01-01 10:00:00"

Wow. Yeah, that'll make exploiting this *much* easier on desktop.

Fortunately Ubuntu Server doesn't allow this without authenticating.

This bug was fixed in the package sudo - 1.8.12-1ubuntu1

---------------
sudo (1.8.12-1ubuntu1) wily; urgency=medium

  * Merge from Debian unstable. (LP: #1451274, LP: #1219337)
    Remaining changes:
    - debian/rules:
      + compile with --without-lecture --with-tty-tickets --enable-admin-flag
      + install man/man8/sudo_root.8 in both flavours
      + install apport hooks
    - debian/sudoers:
      + also grant admin group sudo access
    - debian/source_sudo.py, debian/sudo-ldap.dirs, debian/sudo.dirs:
      + add usr/share/apport/package-hooks
    - debian/sudo.pam:
      + Use pam_env to read /etc/environment and /etc/default/locale
        environment files. Reading ~/.pam_environment is not permitted due to
        security reasons.
    - debian/control:
      + dh-autoreconf dependency fixes missing-build-dependency-for-dh_-command
    - Remaining patches:
      + keep_home_by_default.patch: Keep HOME in the default environment
      + debian/patches/also_check_sudo_group.diff: also check the sudo group
        in plugins/sudoers/sudoers.c to create the admin flag file. Leave the
        admin group check for backwards compatibility.
  * Dropped patches no longer needed:
      + add_probe_interfaces_setting.diff
      + actually-use-buildflags.diff
      + CVE-2014-9680.patch

sudo (1.8.12-1) unstable; urgency=low

  * new upstream version, closes: #772707, #773383
  * patch from Christian Kastner to fix sudoers handling error when moving
    between sudo and sudo-ldap packages, closes: #776137

sudo (1.8.11p2-1) unstable; urgency=low

  * new upstream version

sudo (1.8.11p1-2) unstable; urgency=low

  * patch from Jakub Wilk to fix 'ignoring time stamp from the future'
    messages, closes: #762465
  * upstream patch forwarded by Laurent Bigonville that fixes problem with
    Linux kernel auditing code, closes: #764817

sudo (1.8.11p1-1) unstable; urgency=low

  * new upstream version, closes: #764286
  * fix typo in German translation, closes: #761601

sudo (1.8.10p3-1) unstable; urgency=low

  * new upstream release
  * add hardening=+all to match login and su
  * updated VCS URLs and crypto verified watch file, closes: #747473
  * harmonize configure options for LDAP version to match non-LDAP version,
    in particular stop using --with-secure-path and add configure_args
  * enable audit support on Linux systems, closes: #745779
  * follow upstream change from --with-timedir to --with-rundir

 -- Marc Deslauriers <email address hidden> Wed, 13 May 2015 15:43:49 -0400

FYI, the current plan is to wait until Debian bug #786555 gets fixed, and then publish updates for stable Ubuntu releases based on the jessie sudo package.

It looks like sudo 1.8.12 made it into 15.10 finally. Excellent. Apple went the other route and locked the clock back down. (https://support.apple.com/en-us/HT205031)

The CVE associated with this bug seems to be about the TZ (seen on RedHat's security site: https://access.redhat.com/security/cve/CVE-2014-9680). Apple's CVE is about restricting access to the time settings (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3757). I don't think either one really reflects this bug.

utopic has seen the end of its life and is no longer receiving any updates. Marking the utopic task for this ticket as "Won't Fix".

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release