The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: sudo (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
** Changed in: gnome-control-center
Status: Unknown => Confirmed
** Changed in: gnome-control-center
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
** Changed in: sudo (Ubuntu Vivid)
Status: Triaged => Won't Fix
** CVE removed: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-9680
** CVE removed: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2015-3757
** Project changed: unity => ubuntu-translations
** No longer
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".
** Changed in: sudo (Ubuntu Utopic)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Desktop
Packages, which
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:
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in
** Branch linked: lp:ubuntu/sudo
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock without authenticating, allowing them
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
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 received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in
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.
--
You received this bug notification because you are a member of Desktop
Packages,
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 received this bug notification because you are a
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
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
3 = inode of the tty file
01000 = uid of the tty file
5 = gid of the tty file
31291 = sid
The id of the device the tty is on is known. So is the
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.
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
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
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
Yes, there's a chance the same tty can get reused with the same inode if
nothing else requires a tty in the meantime.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
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
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in
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.
--
You received this bug notification because
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.
:)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
You can set the time with:
timedatectl set-time 2000-01-01 10:00:00
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is
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 received this bug notification because you are a member of Desktop
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.
** Changed in: sudo (Ubuntu Precise)
Status: Confirmed = Triaged
** Changed in: sudo (Ubuntu Precise)
Importance: Undecided = Low
** Changed in: sudo (Ubuntu Trusty)
Status: Confirmed = Triaged
** Changed in: sudo (Ubuntu Trusty)
Importance: Undecided = Low
** Changed in:
** Also affects: gnome-control-center via
https://bugzilla.gnome.org/show_bug.cgi?id=646185
Importance: Unknown
Status: Unknown
** No longer affects: gnome-control-center
** Bug watch added: GNOME Bug Tracker #646185
https://bugzilla.gnome.org/show_bug.cgi?id=646185
** Project
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
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
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,
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,
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
** Also affects: sudo (Ubuntu Utopic)
Importance: Undecided
Status: New
** Also affects: policykit-desktop-privileges (Ubuntu Utopic)
Importance: Undecided
Status: New
** Also affects: sudo (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects:
** Changed in: sudo (Ubuntu Precise)
Assignee: (unassigned) = Marc Deslauriers (mdeslaur)
** Changed in: sudo (Ubuntu Trusty)
Assignee: (unassigned) = Marc Deslauriers (mdeslaur)
** Changed in: sudo (Ubuntu Utopic)
Assignee: (unassigned) = Marc Deslauriers (mdeslaur)
** 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
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is
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.
--
You received this bug notification because you are a member of Desktop
** Package changed: gnome-control-center (Ubuntu) = policykit-desktop-
privileges (Ubuntu)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users
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 19850101 during the boot? Shouldn't they
be set to
@Eero: yes, I noticed that while investigating last night also. I'll
file a bug, and a bug with Debian.
** Also affects: sudo (Ubuntu)
Importance: Undecided
Status: New
** Changed in: sudo (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a
@Eero: I've filed bug 1223297 in Ubuntu, 722335 in debian.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock without
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
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?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
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
Perhaps we could also investigate a way for gnome-control-center's
timedated to invalidate sudo authentication files when the system date
is changed.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
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
** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2013-1775
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock
** CVE removed: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2013-1775
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock
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
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.
--
You received
** Also affects: sudo
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock without
** Bug watch added: Sudo Bugzilla #616
http://www.sudo.ws/bugs/show_bug.cgi?id=616
** Changed in: sudo
Importance: Undecided = Unknown
** Changed in: sudo
Status: New = Unknown
** Changed in: sudo
Remote watch: None = Sudo Bugzilla #616
--
You received this bug notification
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. :)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
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?!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in
Todd C Miller is working on it from the sudo side upstream, potentially
using CLOCK_MONOTONIC.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can
oh, that would be great!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock without authenticating, allowing them to
locally
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
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
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
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
Are you really sure users are supposed to be able to bypass sudo like
that?
** Changed in: gnome-control-center (Ubuntu)
Status: Invalid = New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
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
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
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock without
65 matches
Mail list logo
