Not good in principle, mostly because it seems pretty sloppy. In terms of impact, though, I would guess the vulnerable configuration is incredibly rare?
The privilege escalation scenario here is that you’ve given a user sudoers access to run commands as (ALL, !root), i.e. as any user except root. This bug lets them upgrade that into being able to run them as root, also. Is there any remotely common scenario where you would have that kind of sudoers setup? I can vaguely imagine something like that from old-school multiuser academic Unix servers, but even there it’d be a somewhat exotic setup (restricted sudoers there are typically restricted to specific users they can sudo to, like the apache user or something, or a prof being able to sudo to their students, but not to ALL, !root).
I struggle to see how exactly one would set up a system where a user can run code as if they were a user with access to run sudo as root, where the user couldn’t exploit that to gain root. If Alice has sudo access without root, and Bob has sudo access with root, couldn’t Alice just make Bob’s .bashrc alias ‘sudo’ to ‘sudo chmod -aG wheel Alice;’? With some extra logic to make it undetectable (make the command Bob tried to run actually work, delete the line from .bashrc once it’s run).
Yeah, you the administrator would still need to set up user privileges to avoid that kind of transitive escalation scenario. I imagine that in the old days of Unix multi-user systems, this was common knowledge. Now that there are more computers than people and every user must admin their own laptop, it seems that the nuances have largely collapsed into just two modes: “root” and “unprivileged”.
I suppose you could have a system where the administrator (Bob, in this case) only ever administers the system by remotely logging in from a different machine directly as root, or by sitting in front of the TTY and logging in as root. Surely, any solution where Bob would at any point elevate his own rights to root from within a Bob user session would also allow Alice to elevate her rights to root.
Sorry if I wasn’t clear. Alice shouldn’t ever be allowed to run commands as Bob. She should only be able to run commands as other users with fewer privileges than her.
But that’s not the kind of setup which would be affected by this sudo issue. The issue is specifically that if root is blacklisted but any other user is allowed, you could sudo to user root by passing in UID -1 or 4294967295.
If Alice’s entry in the sudoers file only allows her to sudo as a whitelisted set of users, this sudo CVE would be irrelevant; sudo would see that UID -1 or 4294967295 isn’t one of the users there’s allowed to sudo as, even if sudo didn’t think those UIDs belong to root.
There’s at least one other way to get full sudo from restricted sudo, and I don’t think that one’s going to be fixed, so fixing this CVE won’t really help anyway.
That’s a slightly different kind of restriction, though. Things giving away root is arguably the things’ problem (or at least the administrator’s, for giving root access to insufficiently secure things). This is the opposite problem—sudo giving out root access in an otherwise-secure configuration (even if it would take a bit of work to make (ALL !root) secure in practice).
Sure. What sudo does is widen the attack surface by providing that root-for-some-commands feature, and implement the feature such that the things have to be maximally careful, by providing the originating user’s own environment unfiltered instead of providing root’s environment.
IIRC providing the user’s environment is a deliberate design decision.
Not good in principle, mostly because it seems pretty sloppy. In terms of impact, though, I would guess the vulnerable configuration is incredibly rare?
The privilege escalation scenario here is that you’ve given a user sudoers access to run commands as (ALL, !root), i.e. as any user except root. This bug lets them upgrade that into being able to run them as root, also. Is there any remotely common scenario where you would have that kind of sudoers setup? I can vaguely imagine something like that from old-school multiuser academic Unix servers, but even there it’d be a somewhat exotic setup (restricted sudoers there are typically restricted to specific users they can sudo to, like the apache user or something, or a prof being able to sudo to their students, but not to ALL, !root).
I struggle to see how exactly one would set up a system where a user can run code as if they were a user with access to run sudo as root, where the user couldn’t exploit that to gain root. If Alice has sudo access without root, and Bob has sudo access with root, couldn’t Alice just make Bob’s .bashrc alias ‘sudo’ to ‘sudo chmod -aG wheel Alice;’? With some extra logic to make it undetectable (make the command Bob tried to run actually work, delete the line from .bashrc once it’s run).
Yeah, you the administrator would still need to set up user privileges to avoid that kind of transitive escalation scenario. I imagine that in the old days of Unix multi-user systems, this was common knowledge. Now that there are more computers than people and every user must admin their own laptop, it seems that the nuances have largely collapsed into just two modes: “root” and “unprivileged”.
I suppose you could have a system where the administrator (Bob, in this case) only ever administers the system by remotely logging in from a different machine directly as root, or by sitting in front of the TTY and logging in as root. Surely, any solution where Bob would at any point elevate his own rights to root from within a Bob user session would also allow Alice to elevate her rights to root.
Sorry if I wasn’t clear. Alice shouldn’t ever be allowed to run commands as Bob. She should only be able to run commands as other users with fewer privileges than her.
But that’s not the kind of setup which would be affected by this sudo issue. The issue is specifically that if root is blacklisted but any other user is allowed, you could sudo to user root by passing in UID -1 or 4294967295.
If Alice’s entry in the sudoers file only allows her to sudo as a whitelisted set of users, this sudo CVE would be irrelevant; sudo would see that UID -1 or 4294967295 isn’t one of the users there’s allowed to sudo as, even if sudo didn’t think those UIDs belong to root.
Exactly my point.
Just use DOAS. Its secure.
“Just speak Chinese.” Source: I’ve tried DOAS.
If only Chinese had such nice man pages…
What if you’re not a BSD user?
DOAS is portable, I use it on Red Hat, CentOS and Oracle Linux systems, Ubuntu should also not be a problem.
Read those commits and the commit messages. Then reconsider if you really want to say doas is secure, if you use a random port.
Nothing is perfect and doas is quite young comparing to sudo (about 15 years difference).
There’s at least one other way to get full sudo from restricted sudo, and I don’t think that one’s going to be fixed, so fixing this CVE won’t really help anyway.
That’s a slightly different kind of restriction, though. Things giving away root is arguably the things’ problem (or at least the administrator’s, for giving root access to insufficiently secure things). This is the opposite problem—sudo giving out root access in an otherwise-secure configuration (even if it would take a bit of work to make
(ALL !root)secure in practice).Sure. What sudo does is widen the attack surface by providing that root-for-some-commands feature, and implement the feature such that the things have to be maximally careful, by providing the originating user’s own environment unfiltered instead of providing root’s environment.
IIRC providing the user’s environment is a deliberate design decision.
What to do with the environment is configurable. I admit I’m not sure quite why preserving it is the default.
so happy that the BSDs don’t come with sudo installed, but OpenBSD’s doas is way better.
I use DOAS on FreeBSD and also Red Hat/CentOS/Oracle Linux, works like a charm.
Don’t panic, apply patches: https://launchpad.net/ubuntu/+source/sudo/1.8.21p2-3ubuntu1.1
I’m surprised systemd is not involved here. ;)
Downvoted as off-topic for blatant axe-grinding.
Thanks for explaining the downvote. The smiley at the end was meant as an indication to not take it that seriously.
Suggest folding into https://lobste.rs/s/zirgzc/sudo_flaw_lets_linux_users_run_commands_as
(the linked article isn’t responding at this time)
Thank you @gerikson, I’ve merged story xbq2tv in to zirgzc.
https://www.sudo.ws/repos/sudo/rev/83db8dba09e7 Treat an ID of -1 as invalid since that means “no change”.