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.<p>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.<p>Since the user ID -1 isn't a real thing, this only ever happens if you allow a user to sudo as <i>anyone</i>, including root. Then for the bug to matter, you have to <i>explicitly exclude</i> root. This is an extremely weird configuration. It makes little to no sense.<p>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.
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.<p>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<p>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.
I love the logo for Sudo<p><a href="https://www.sudo.ws/sudo/images/sudo-logo-65.png" rel="nofollow">https://www.sudo.ws/sudo/images/sudo-logo-65.png</a>
Sudo has too much surface area for a suid utility IMHO, unnecessary pile of features, config parsing, etc.<p>I still just use `su` with the wheel group membership executable requirement for gaining root privileges from my regular user.<p>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.<p>Do you know the list of suid binaries installed on your machine?<p>`find / -perm -4000 -printf '%#m %u %p\n'`
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.<p>Some others: <a href="https://www.sudo.ws/other.html" rel="nofollow">https://www.sudo.ws/other.html</a>
For the curious, this is the patch that fixes it: <a href="https://www.sudo.ws/repos/sudo/rev/83db8dba09e7" rel="nofollow">https://www.sudo.ws/repos/sudo/rev/83db8dba09e7</a>
I have a hard time understanding this explanation:<p>> For example, it can be used by a local user who wants to run commands as root — the windows equivalent of admin user.<p>"root" is the "windows equivalent" of "admin user"?<p>But then he talks about rules where you give someone the "sudo" permission to run a command as anyone _other_ than root<p>> jacob myhost = (ALL, !root) /usr/bin/chmod<p>> 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?<p>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.
The underlying issue in my opinion is the terrible interface of setresuid(2): <a href="http://man7.org/linux/man-pages/man2/setresuid.2.html" rel="nofollow">http://man7.org/linux/man-pages/man2/setresuid.2.html</a>
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)<p><a href="https://www.openwall.com/lists/oss-security/2019/10/14/1" rel="nofollow">https://www.openwall.com/lists/oss-security/2019/10/14/1</a><p>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.<p>> 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.<p>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]<p>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.<p>[0] <a href="http://man7.org/linux/man-pages/man2/setresuid.2.html" rel="nofollow">http://man7.org/linux/man-pages/man2/setresuid.2.html</a><p>[1] <a href="http://man7.org/linux/man-pages/man2/setreuid.2.html" rel="nofollow">http://man7.org/linux/man-pages/man2/setreuid.2.html</a>