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 policykit-desktop-privi
** 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.
https://
** 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 affects:
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 is
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/C
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 Ub
** 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 to
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-fla
> 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, w
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 U
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.
https:/
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 Ubun
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 wi
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
Packages,
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 subscribed
Yup, I think so. while true; do setsid ; 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.
--
You r
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.
https://bugs.launchpad.net/bugs/12193
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.
https://bugs.launchpad.net/bugs/
> 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 cl
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.
https:
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 memb
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 su
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.
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 u
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 p
** 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 ch
** 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
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.
> 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,
/*
* 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;
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
d
** 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: policyki
** 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
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
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
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 subscribe
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
Pac
** 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 ca
@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 authenticating
@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
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 ep
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.
https://
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
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.
https://bugs.lau
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
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 explo
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 cha
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 Ubun
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 gnome-
** 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 be
** 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 authent
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.c
> 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
> 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 defaul
** 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 with
** 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 withou
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
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
>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 a
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 t
** 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 authenticating
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
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 pas
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.
https:
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.me
66 matches
Mail list logo
