10 ms·

Sudo vulnerability

noncoml 7y ago
For the curious, this is the patch that fixes it: https://www.sudo.ws/repos/sudo/rev/83db8dba09e7 https://www.sudo.ws/repos/sudo/rev/83db8dba09e7
tyingq 7y ago
It's interesting to me that sudo is so ubiquitous versus the alternatives. I remember "super" being a somewhat popular alternative in the 90's, but that faded. Some others: https://www.sudo.ws/other.html https://www.sudo.ws/other.html
- AdmiralAsshat 7y ago
  Company I used to work for had an elevated user they'd create on supported customer systems literally called "backdoor". Needless to say, that raised some eyebrows during the audits.
keyle 7y ago
Personally I'm amazed that this is only discovered today. Wink wink nudge nudge.
newnewpdro 7y ago
Sudo has too much surface area for a suid utility IMHO, unnecessary pile of features, config parsing, etc. I still just use `su` with the wheel group membership executable requirement for gaining root privileges from my regular user. But sudo has become quite entrenched, almost every software deployment guide I see expects sudo, many scripts outright break on the assumption of sudo being present. Do you know the list of suid binaries installed on your machine? `find / -perm -4000 -printf '%#m %u %p\n'`
- simcop2387 7y ago
  The thing is, sudo also tries to allow you to give much more limited access also. Such as run specific commands as another user without needing full root access. That does present a larger surface on the part of sudo, but it's a considerably tiny surface compared to giving the user full access with su and wheel.
- yjftsjthsd-h 7y ago
  Yeah, I started using OpenBSD's doas and it's surprising how many things expect sudo specifically.
  - tomrod 7y ago
    For the most part, could you alias doas to sudo?
    - jlgaddis 7y ago
      FWIW, I did exactly that on my OpenBSD machines when doas was first introduced and I can't think of any issues I've encountered.
    - yjftsjthsd-h 7y ago
      Maybe? The one that sticks out in my memory is running sshuttle on Arch Linux; Arch considers sudo to be part of the base group, so it doesn't want to remove the package, and I think sshuttle invokes /usr/bin/sudo with special options to control it. But... I might try just making a sudo symlink in my path and see how it behaves; thanks for the idea:)
- jean23 7y ago
  When all you have is a single user machine, and "gain root from my regular user" is all you want, su is enough. Yes, sudo has a few more features, but just because you don't need them doesn't mean they are necessarily "unnecessary". And if you look at the bug – that bug wouldn't have occurred in your setup. You could replicate the functionality where this bug occurs with sudo and pam, but I don't really think that's less "surface area", and I know the chance that I would muck up re-implementing sudo functionality that way with a greater chance than the sudo devs.
  - newnewpdro 7y ago
    I use the same strategy on the multi-user shell machine I operate. The few trusted admins are in the wheel group, there's no root logins over ssh, and there's no sudo. The regular users don't get to switch users and definitely don't get access to root even if they know the root password since they're not members of wheel. Sudo has never seemed like a good idea to me, but I've never had the inclination to let some users do just some things as root. Most programs have ways to escape and get to a shell somehow, so relying on sudo to restrict access to specific programs is often fundamentally flawed because those programs themselves are more often than not incapable of restricting the user from escaping them with the elevated privs.
- isostatic 7y ago
  We have an ever changing group of about 60 engineers who need the ability to do rooty style things on about 500 different machines (very few of which are the same, so things like ansible don't work too well). While only a handful actually do, the rest need to be able to, and they're trusted to make the call. However we still want to know what's going on, and sudo fires back a message to syslog with who did it and what they did. Far more useful than "joebloggs went to root at 03:14 and logged out at 09:15"
  - jlgaddis 7y ago
    If you take the time (once) to configure it correctly, auditd can tell you much, much more than just what commands were executed (and "hiding" the commands you ran via sudo is fairly trivial, if one is so inclined).
    - isostatic 7y ago
      Wouldn't that simply say "root did this at this time", and maybe "on this pts", and then I'd have to marry that up with who was logged on at the given pts at that time? Either way we don't sue sudo to enforce security -- anyone could go and reboot the machine physically in any case, we use sudo so we remember what we did, or can quickly find the person who did it. Same with physical security, we don't stop people from pulling the plug, but if the plug is pulled we can see who was probably in the room at the time. You can work around it (by going in with a colleague) if you wanted to hide your tracks, but people don't hide their tracks. Of course the other benefit of sudo is to reduce the number of terminals logged in as root, where accidents can easilly happen.
Exuma 7y ago
I love the logo for Sudo https://www.sudo.ws/sudo/images/sudo-logo-65.png https://www.sudo.ws/sudo/images/sudo-logo-65.png
- bonoboTP 7y ago
  It's a reference to https://xkcd.com/149/ https://xkcd.com/149/ right?
  - aaron_m04 7y ago
    It has to be.
  - Exuma 7y ago
    Damn... that makes it even funnier.
kdbg 7y ago
The original announcement email does a much better job of explaining the actual vulnerability, and the configuration under which its an issue (using ALL and !root in the runas part of the sudoers entry) https://www.openwall.com/lists/oss-security/2019/10/14/1 https://www.openwall.com/lists/oss-security/2019/10/14/1 This writeup does little to explain the issue beyond showing a config line that is vulnerable (but doesn't really explain which part makes it vulnerable). It also incorrectly states the issue is sudo failing to parse the value correctly. > the function fails to parse all values correctly and when giving the parameter user id “-1” or its unsigned number “4294967295”, the command will run as root, bypassing the security policy entry we set in the example above. Which is incorrect, sudo parses the value just fine, the issue comes from the `setresuid` and `setreuid` calls. Both treat -1 as a special case that means the corresponding value should not be modified.[0][1] I mean, sure this article gets the key point that -u#-1 gets you root, but if you're explaining a vulnerability I'd expect the technical details to be correct. [0] http://man7.org/linux/man-pages/man2/setresuid.2.html http://man7.org/linux/man-pages/man2/setresuid.2.html [1] http://man7.org/linux/man-pages/man2/setreuid.2.html http://man7.org/linux/man-pages/man2/setreuid.2.html
- breadandcrumbel 7y ago
  I googled the writer name ( Daniel Elkabes, Lead Security Researcher ) Found his Linkedin and sent him a screenshoot of your feedback That's the kind of feedback that can improve the writing skill of the author Edit: Now I'm actually thinking that not every person know how to accept negative feedback and see it as something positve I know that I would like to see this feedback if I was the author so I felt like sending it.
  - gregoryl 7y ago
    You should be safe to assume anyone sitting in a lead role should be very comfortable with negative feedback, I'd not stress.
    - asveikau 7y ago
      It would be nice to imagine the world as it should be, but I don't think this is actually super common.
svnpenn 7y ago
No date at all in the article. It helps to have that for context.
- bad-joke 7y ago
  That confused me too. Internet Archive has earliest at 10/17/2019[1] and the page contains a link[2] to the Sudo team security alert on 10/14/2019. [1] https://web.archive.org/web/20191017233613/https://resources.whitesourcesoftware.com/blog-whitesource/new-vulnerability-in-sudo-cve-2019-14287 https://web.archive.org/web/20191017233613/https://resources... [2] https://www.sudo.ws/alerts/minus_1_uid.html https://www.sudo.ws/alerts/minus_1_uid.html
  - breadandcrumbel 7y ago
    Does Web Archive screenshoot all the webpages out-there every day? If there is few days gap between each site screenshoot it might be the answer
- jwilk 7y ago
  The article URL has been updated to https://www.openwall.com/lists/oss-security/2019/10/14/1 https://www.openwall.com/lists/oss-security/2019/10/14/1 , which has: Date: Mon, 14 Oct 2019 09:00:31 -0600
WC3w6pXxgGd 7y ago
Pretty big oversight to not handle -1 or 2³².
slovenlyrobot 7y ago
For anyone with a modicum of C spending any amount of time in the sudo codebase, this isn't much surprise. It's the scariest piece of organically grown security-sensitive code I'm aware of still in popular use. It's jam-packed with features you've never even heard of, and has quite surprising functional changes across versions that never make the changelog and require diffing to discover. It's hard to quantify that "this code is obviously wrong" feeling, for example liberal intermixing of concerns within a single procedure in many places of the code. Options with little to no security value (requiretty) documented as if they do, the ability to pass control to user-supplied policy plug-ins from a setuid binary, etc. There is just far too much going on to expect it not to regularly break Ignoring the implementation, I think it's fair to say sudo is broken in concept, simply by trying to have this kind of expressive policy language in the first place. The set of skills required to safely expose some subset of functionality to an untrustworthy user is perfectly distinct from those involved in typical sysadmin.
- mehrdadn 7y ago
  > Ignoring the implementation, I think it's fair to say sudo is broken in concept IMO you're not going far enough. The whole UNIX setuid notion is fundamentally broken to me. The ability to execute a file should logically have nothing to do with the permissions granted to you when doing so. Windows gets this right.
  - iancarroll 7y ago
    How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.
    - minitech 7y ago
      Which UAC bypasses have they refused to fix?
      - mehrdadn 7y ago
fortran77 7y ago
I have a hard time understanding this explanation: > For example, it can be used by a local user who wants to run commands as root — the windows equivalent of admin user. "root" is the "windows equivalent" of "admin user"? But then he talks about rules where you give someone the "sudo" permission to run a command as anyone _other_ than root > jacob myhost = (ALL, !root) /usr/bin/chmod > This entry means that user jacob is allowed to run “chmod” as any user except the root user, meaning a security policy is in place in order to limit access — sounds good, right? So that means "sudo" is a way to run a command as a different user, which may or may not be root depending on policy.
- jwilk 7y ago
  > "sudo" is a way to run a command as a different user, which may or may not be root depending on policy. Correct. Letting a normal user run commands as root is the most common use-case for sudo, which is why it was mentioned as an example earlier. The bug does not trigger in this common setup, only in a quite unusual one mentioned later. Perhaps that should have been said explicitly.
fortran77 7y ago
How can bugs like this be prevented? Is Linix/Unix "sudo" security model simply flawed?
- asveikau 7y ago
  Not rust, but the OpenBSD folks wrote doas(1). Also I am not sure how rust solves this bug, I don't think it's about memory safety is it? This is about passing -1 from a config file to a syscall, and sudo not validating the value or it being written without the understanding of what -1 means to that syscall. Nothing is mis-parsed, no buffers overflowed, etc.
  - nkozyra 7y ago
    > Also I am not sure how rust solves this bug Giving the benefit of the doubt I think this was in jest edit: comment history confirms
  - aquabeagle 7y ago
    Fun fact: sudo is maintained by an OpenBSD developer
  - marcan_42 7y ago
    It's a type confusion mistake (-1, meaning "no user ID", being the same type as an actual user ID). Idiomatic Rust would largely prevent this kind of mistake (you'd use an enum type, with a distinct value for "no user"), as long as someone first writes an idiomatic Rust wrapper for the syscalls. Obviously, if you write the Rust the same way you'd write the C, then yeah, the mistake is equally likely to happen. Rust encourages style that avoids this kind of problem, but it can't enforce it.
    - asveikau 7y ago
      So supposing you have a type that can either be a uid_t or no value... Can you specify that the high bit on the uid_t cannot be set? I.e. prevent an explicit stuffing of negative values (or unsigned values that are bit-identical to negative ones in the corresponding signed types) into such a type? That is the most explicit way I can think of to block this with a type system. If uid_t is 32 bits, you need a type that can either contain 31 bits or no value, to prevent that 32nd bit being stuffed into the syscall somehow.
ignoranceprior 7y ago
How should Mac OS users update sudo?
- kitotik 7y ago
  Wait for Apple to push an update or prepare for unexpected wonkiness if you touch Apple-provided binaries.
- stouset 7y ago
  I am pretty confident in stating that this bug impacts roughly zero macOS systems globally.
marcan_42 7y ago
This is already two week old news, and it affects an extremely limited number of systems. Almost nobody should be using a configuration that is vulnerable, so the number of impacted systems is negligible. You don't have to care about this bug, really. The bug can be more simply restated as follows: if you allow a user to sudo to the unnamed user ID '-1', you also allow them to sudo to root. Since the user ID -1 isn't a real thing, this only ever happens if you allow a user to sudo as anyone, including root. Then for the bug to matter, you have to explicitly exclude root. This is an extremely weird configuration. It makes little to no sense. In fact, it's quite likely that if you're using such a config, you're already vulnerable to privilege escalation anyway, without any sudo bugs. For example, on many systems, the 'adm' user can write to raw disk devices, and thus give itself root access by directly modifying the filesystem. If you use an 'anyone but root' rule on such a system, then it's trivial to escalate to root anyway.
commandersaki 7y ago
The underlying issue in my opinion is the terrible interface of setresuid(2): http://man7.org/linux/man-pages/man2/setresuid.2.html http://man7.org/linux/man-pages/man2/setresuid.2.html

For the curious, this is the patch that fixes it: https://www.sudo.ws/repos/sudo/rev/83db8dba09e7 https://www.sudo.ws/repos/sudo/rev/83db8dba09e7

tyingq 7y ago

It's interesting to me that sudo is so ubiquitous versus the alternatives. I remember "super" being a somewhat popular alternative in the 90's, but that faded. Some others: https://www.sudo.ws/other.html https://www.sudo.ws/other.html

AdmiralAsshat 7y ago
Company I used to work for had an elevated user they'd create on supported customer systems literally called "backdoor". Needless to say, that raised some eyebrows during the audits.

keyle 7y ago

Personally I'm amazed that this is only discovered today. Wink wink nudge nudge.

newnewpdro 7y ago

Sudo has too much surface area for a suid utility IMHO, unnecessary pile of features, config parsing, etc. I still just use `su` with the wheel group membership executable requirement for gaining root privileges from my regular user. But sudo has become quite entrenched, almost every software deployment guide I see expects sudo, many scripts outright break on the assumption of sudo being present. Do you know the list of suid binaries installed on your machine? `find / -perm -4000 -printf '%#m %u %p\n'`

simcop2387 7y ago
The thing is, sudo also tries to allow you to give much more limited access also. Such as run specific commands as another user without needing full root access. That does present a larger surface on the part of sudo, but it's a considerably tiny surface compared to giving the user full access with su and wheel.
yjftsjthsd-h 7y ago
Yeah, I started using OpenBSD's doas and it's surprising how many things expect sudo specifically.
- tomrod 7y ago
  For the most part, could you alias doas to sudo?
  - jlgaddis 7y ago
    FWIW, I did exactly that on my OpenBSD machines when doas was first introduced and I can't think of any issues I've encountered.
  - yjftsjthsd-h 7y ago
    Maybe? The one that sticks out in my memory is running sshuttle on Arch Linux; Arch considers sudo to be part of the base group, so it doesn't want to remove the package, and I think sshuttle invokes /usr/bin/sudo with special options to control it. But... I might try just making a sudo symlink in my path and see how it behaves; thanks for the idea:)
jean23 7y ago
When all you have is a single user machine, and "gain root from my regular user" is all you want, su is enough. Yes, sudo has a few more features, but just because you don't need them doesn't mean they are necessarily "unnecessary". And if you look at the bug – that bug wouldn't have occurred in your setup. You could replicate the functionality where this bug occurs with sudo and pam, but I don't really think that's less "surface area", and I know the chance that I would muck up re-implementing sudo functionality that way with a greater chance than the sudo devs.
- newnewpdro 7y ago
  I use the same strategy on the multi-user shell machine I operate. The few trusted admins are in the wheel group, there's no root logins over ssh, and there's no sudo. The regular users don't get to switch users and definitely don't get access to root even if they know the root password since they're not members of wheel. Sudo has never seemed like a good idea to me, but I've never had the inclination to let some users do just some things as root. Most programs have ways to escape and get to a shell somehow, so relying on sudo to restrict access to specific programs is often fundamentally flawed because those programs themselves are more often than not incapable of restricting the user from escaping them with the elevated privs.
isostatic 7y ago
We have an ever changing group of about 60 engineers who need the ability to do rooty style things on about 500 different machines (very few of which are the same, so things like ansible don't work too well). While only a handful actually do, the rest need to be able to, and they're trusted to make the call. However we still want to know what's going on, and sudo fires back a message to syslog with who did it and what they did. Far more useful than "joebloggs went to root at 03:14 and logged out at 09:15"
- jlgaddis 7y ago
  If you take the time (once) to configure it correctly, auditd can tell you much, much more than just what commands were executed (and "hiding" the commands you ran via sudo is fairly trivial, if one is so inclined).
  - isostatic 7y ago
    Wouldn't that simply say "root did this at this time", and maybe "on this pts", and then I'd have to marry that up with who was logged on at the given pts at that time? Either way we don't sue sudo to enforce security -- anyone could go and reboot the machine physically in any case, we use sudo so we remember what we did, or can quickly find the person who did it. Same with physical security, we don't stop people from pulling the plug, but if the plug is pulled we can see who was probably in the room at the time. You can work around it (by going in with a colleague) if you wanted to hide your tracks, but people don't hide their tracks. Of course the other benefit of sudo is to reduce the number of terminals logged in as root, where accidents can easilly happen.

Exuma 7y ago

I love the logo for Sudo https://www.sudo.ws/sudo/images/sudo-logo-65.png https://www.sudo.ws/sudo/images/sudo-logo-65.png

bonoboTP 7y ago
It's a reference to https://xkcd.com/149/ https://xkcd.com/149/ right?
- aaron_m04 7y ago
  It has to be.
- Exuma 7y ago
  Damn... that makes it even funnier.

kdbg 7y ago

The original announcement email does a much better job of explaining the actual vulnerability, and the configuration under which its an issue (using ALL and !root in the runas part of the sudoers entry) https://www.openwall.com/lists/oss-security/2019/10/14/1 https://www.openwall.com/lists/oss-security/2019/10/14/1 This writeup does little to explain the issue beyond showing a config line that is vulnerable (but doesn't really explain which part makes it vulnerable). It also incorrectly states the issue is sudo failing to parse the value correctly. > the function fails to parse all values correctly and when giving the parameter user id “-1” or its unsigned number “4294967295”, the command will run as root, bypassing the security policy entry we set in the example above. Which is incorrect, sudo parses the value just fine, the issue comes from the `setresuid` and `setreuid` calls. Both treat -1 as a special case that means the corresponding value should not be modified.[0][1] I mean, sure this article gets the key point that -u#-1 gets you root, but if you're explaining a vulnerability I'd expect the technical details to be correct. [0] http://man7.org/linux/man-pages/man2/setresuid.2.html http://man7.org/linux/man-pages/man2/setresuid.2.html [1] http://man7.org/linux/man-pages/man2/setreuid.2.html http://man7.org/linux/man-pages/man2/setreuid.2.html

breadandcrumbel 7y ago
I googled the writer name ( Daniel Elkabes, Lead Security Researcher ) Found his Linkedin and sent him a screenshoot of your feedback That's the kind of feedback that can improve the writing skill of the author Edit: Now I'm actually thinking that not every person know how to accept negative feedback and see it as something positve I know that I would like to see this feedback if I was the author so I felt like sending it.
- gregoryl 7y ago
  You should be safe to assume anyone sitting in a lead role should be very comfortable with negative feedback, I'd not stress.
  - asveikau 7y ago
    It would be nice to imagine the world as it should be, but I don't think this is actually super common.

svnpenn 7y ago

No date at all in the article. It helps to have that for context.

bad-joke 7y ago
That confused me too. Internet Archive has earliest at 10/17/2019[1] and the page contains a link[2] to the Sudo team security alert on 10/14/2019. [1] https://web.archive.org/web/20191017233613/https://resources.whitesourcesoftware.com/blog-whitesource/new-vulnerability-in-sudo-cve-2019-14287 https://web.archive.org/web/20191017233613/https://resources... [2] https://www.sudo.ws/alerts/minus_1_uid.html https://www.sudo.ws/alerts/minus_1_uid.html
- breadandcrumbel 7y ago
  Does Web Archive screenshoot all the webpages out-there every day? If there is few days gap between each site screenshoot it might be the answer
jwilk 7y ago
The article URL has been updated to https://www.openwall.com/lists/oss-security/2019/10/14/1 https://www.openwall.com/lists/oss-security/2019/10/14/1 , which has: Date: Mon, 14 Oct 2019 09:00:31 -0600

WC3w6pXxgGd 7y ago

Pretty big oversight to not handle -1 or 2³².

slovenlyrobot 7y ago

For anyone with a modicum of C spending any amount of time in the sudo codebase, this isn't much surprise. It's the scariest piece of organically grown security-sensitive code I'm aware of still in popular use. It's jam-packed with features you've never even heard of, and has quite surprising functional changes across versions that never make the changelog and require diffing to discover. It's hard to quantify that "this code is obviously wrong" feeling, for example liberal intermixing of concerns within a single procedure in many places of the code. Options with little to no security value (requiretty) documented as if they do, the ability to pass control to user-supplied policy plug-ins from a setuid binary, etc. There is just far too much going on to expect it not to regularly break Ignoring the implementation, I think it's fair to say sudo is broken in concept, simply by trying to have this kind of expressive policy language in the first place. The set of skills required to safely expose some subset of functionality to an untrustworthy user is perfectly distinct from those involved in typical sysadmin.

mehrdadn 7y ago
> Ignoring the implementation, I think it's fair to say sudo is broken in concept IMO you're not going far enough. The whole UNIX setuid notion is fundamentally broken to me. The ability to execute a file should logically have nothing to do with the permissions granted to you when doing so. Windows gets this right.
- iancarroll 7y ago
  How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.
  - minitech 7y ago
    Which UAC bypasses have they refused to fix?
    - mehrdadn 7y ago

fortran77 7y ago

I have a hard time understanding this explanation: > For example, it can be used by a local user who wants to run commands as root — the windows equivalent of admin user. "root" is the "windows equivalent" of "admin user"? But then he talks about rules where you give someone the "sudo" permission to run a command as anyone _other_ than root > jacob myhost = (ALL, !root) /usr/bin/chmod > This entry means that user jacob is allowed to run “chmod” as any user except the root user, meaning a security policy is in place in order to limit access — sounds good, right? So that means "sudo" is a way to run a command as a different user, which may or may not be root depending on policy.

jwilk 7y ago
> "sudo" is a way to run a command as a different user, which may or may not be root depending on policy. Correct. Letting a normal user run commands as root is the most common use-case for sudo, which is why it was mentioned as an example earlier. The bug does not trigger in this common setup, only in a quite unusual one mentioned later. Perhaps that should have been said explicitly.

fortran77 7y ago

How can bugs like this be prevented? Is Linix/Unix "sudo" security model simply flawed?

asveikau 7y ago
Not rust, but the OpenBSD folks wrote doas(1). Also I am not sure how rust solves this bug, I don't think it's about memory safety is it? This is about passing -1 from a config file to a syscall, and sudo not validating the value or it being written without the understanding of what -1 means to that syscall. Nothing is mis-parsed, no buffers overflowed, etc.
- nkozyra 7y ago
  > Also I am not sure how rust solves this bug Giving the benefit of the doubt I think this was in jest edit: comment history confirms
- aquabeagle 7y ago
  Fun fact: sudo is maintained by an OpenBSD developer
- marcan_42 7y ago
  It's a type confusion mistake (-1, meaning "no user ID", being the same type as an actual user ID). Idiomatic Rust would largely prevent this kind of mistake (you'd use an enum type, with a distinct value for "no user"), as long as someone first writes an idiomatic Rust wrapper for the syscalls. Obviously, if you write the Rust the same way you'd write the C, then yeah, the mistake is equally likely to happen. Rust encourages style that avoids this kind of problem, but it can't enforce it.
  - asveikau 7y ago
    So supposing you have a type that can either be a uid_t or no value... Can you specify that the high bit on the uid_t cannot be set? I.e. prevent an explicit stuffing of negative values (or unsigned values that are bit-identical to negative ones in the corresponding signed types) into such a type? That is the most explicit way I can think of to block this with a type system. If uid_t is 32 bits, you need a type that can either contain 31 bits or no value, to prevent that 32nd bit being stuffed into the syscall somehow.

ignoranceprior 7y ago

How should Mac OS users update sudo?

kitotik 7y ago
Wait for Apple to push an update or prepare for unexpected wonkiness if you touch Apple-provided binaries.
stouset 7y ago
I am pretty confident in stating that this bug impacts roughly zero macOS systems globally.

marcan_42 7y ago

This is already two week old news, and it affects an extremely limited number of systems. Almost nobody should be using a configuration that is vulnerable, so the number of impacted systems is negligible. You don't have to care about this bug, really. The bug can be more simply restated as follows: if you allow a user to sudo to the unnamed user ID '-1', you also allow them to sudo to root. Since the user ID -1 isn't a real thing, this only ever happens if you allow a user to sudo as anyone, including root. Then for the bug to matter, you have to explicitly exclude root. This is an extremely weird configuration. It makes little to no sense. In fact, it's quite likely that if you're using such a config, you're already vulnerable to privilege escalation anyway, without any sudo bugs. For example, on many systems, the 'adm' user can write to raw disk devices, and thus give itself root access by directly modifying the filesystem. If you use an 'anyone but root' rule on such a system, then it's trivial to escalate to root anyway.

commandersaki 7y ago

The underlying issue in my opinion is the terrible interface of setresuid(2): http://man7.org/linux/man-pages/man2/setresuid.2.html http://man7.org/linux/man-pages/man2/setresuid.2.html