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 Ubuntu
Touch seeded 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 Ubuntu
Touch seeded packages, which is subscribed to sudo 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 Ubuntu
Touch seeded
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 Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
** Branch linked: lp:ubuntu/sudo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock without authenticating, allowing them to
locally
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 Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
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 Ubuntu
Touch seeded
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
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.
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 Ubuntu
Touch seeded
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 Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
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
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 Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
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 Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
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 Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
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 Ubuntu
Touch seeded packages, which is subscribed to sudo 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 Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1219337
Title:
Users can change the clock without
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 Ubuntu
Touch
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 Ubuntu
Touch seeded packages, which
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,
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
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,
35 matches
Mail list logo
