Is this the official sudo repository?<p><a href="https://www.sudo.ws/repos/sudo/file/f75f786eddd5" rel="nofollow">https://www.sudo.ws/repos/sudo/file/f75f786eddd5</a><p>It has more than 10 thousand commits, ~600 files, and close to 11MB of C code. Also, the code seems to have no unit tests, the main file is 1.4K lines long, has quintuple-nested conditionals and liberally uses goto statements.<p>Am I missing something here?
Are the examples in the advisory statement slightly incorrect? The first example seems to have the user name and host reversed:<p><pre><code> myhost alice = (ALL) /usr/bin/id
</code></pre>
All the examples I've seen of sudoers files do it this way:<p><pre><code> alice myhost = (ALL) /usr/bin/id
</code></pre>
This is important because the host is rarely used; the host field is usually replaced with ALL, meaning the host name is not important for the rule:<p><pre><code> alice ALL = (ALL) /usr/bin/id
</code></pre>
I hope this isn't some new sudoers syntax.<p>As I consider whether this bug impacts my company, I see two types of rules in our sudoers files: (1) rules that let already-privileged users do privileged things and (2) rules that let processes with minimal privileges make an exception to normal security rules. This bug doesn't impact rules for highly privileged users because they already have many ways to do whatever they want. This bug doesn't impact the second type of rules either because those rules specify exactly which user to change to; I tested the '-u#-1' trick with one of those rules on an unpatched sudo and sudo didn't allow it.<p>The behavior I observed seems to match the advisory, which says the exploitable rules are those that don't specify a specific user to run as.<p>Now I wonder: what kind of well-written rule would be exploitable?
I cannot imagine why would one write (ALL, !root) policy -- this seems like a security hole waiting to happen. There are many system users, and I would not be surprised if some of them can be escalated to root.
The fix was done in <a href="https://www.sudo.ws/repos/sudo/rev/83db8dba09e7" rel="nofollow">https://www.sudo.ws/repos/sudo/rev/83db8dba09e7</a><p>The fix appears to be to reject -1 as invalid.<p>The article should have included in the fix section a link to the commit and a summary of what the fix was.
This seems pretty serious, but I wonder if there is a way to measure how many systems are affected by this. Does anyone have telemetry on how many Runas configs are set up this way? How would someone collect this data?
Interesting bug; I wonder what else might be affected by setuid(-1). That said, I’d hope this bug doesn’t really affect too many systems - letting someone run commands as any non-root user is pretty hazardous because some users have really high privileges (e.g. any user in the “docker” group is functionally equivalent to root if Docker is installed).<p>I do love that this command has its own website - and a delightfully on-point XKCD-inspired logo :)