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.
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.
OpenBSD became concerned about sudo's codebase some time ago, and replaced it with the conceptually much simpler doas, which achives about 95% of what sudo does in real world usage.
I've heard of doas sometimes and it's much simpler than sudo, but it's powerful. Doas has two non-official port for Linux[0][1], but it would be great if someone developed an official tool like doas for Linux.
> 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.
_If_ you turn it all the way up. The default setting "3" allows certain "approved" apps to be launched without the UAC prompt, based on what's in their manifest I think. Turn it up to "4" and it works as expected.
If you're looking for a quick way to elevate the Explorer shell, run `hh \` (the Html Help viewer) from an elevated prompt.
What is broken about setuid/setgid? Of course today we have eg SELinux, AppArmor, capsicum and other more sophisticated means, but still the basic setuid mechanism is sound: if you need access to privileged files, you can do so only via trusted setuid programs that only an admin or owner of said privileged file can setup with the setuid bit.
He's probably referring to [1], but he's wrong about UAC (note the sentence "UAC is not a security feature" on that post—the fact that he himself had to put quotes around "security" is itself telling), and moreover, I never claimed anything about UAC in the first place. He's ignoring my point and changing the topic, so I'm not inclined to reply.
I don't know why this reply is so hostile, but I was curious what part of Windows you were referring to if not UAC, because I don't know of anything else.
There is an almost comical list of bypasses in built-in AutoElevate programs that Microsoft does not triage as security bugs because as you note they don't call UAC a security feature. I think this is a rather silly deflection that users are unlikely to understand, for good reason.
I wasn't referring to a "part" at all. What I said Windows gets right was a very fundamental architectural design: the decision to not grant privileges to a process based on the file it's executing (the callee), but rather based on the caller's execution context.
Note, in particular, that there was nothing in my comment that depended on the existence of UAC. Had I written my comment before UAC even existed (say, in the XP era), it would've been exactly the same.
Yet somehow you managed to change the subject of discussion to a very specific feature UAC, a feature that was only introduced around the Vista era and which I had not even mentioned in my comment once. Then you bashed it based on a premise that you already knew was incorrect and therefore had to put in quotes, and then continued as if the point I had been making in my comment all along was to somehow endorse the use of this controversial feature I never mentioned for a purpose that it itself had not been intended. This is not a faithful representation of what I wrote.
Unless "user that was created with admin rights which were later taken away" counts as admin, then no. I always set up a separate admin account and hardly ever have to log into it to do admin stuff.
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?
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.
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"
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).
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.
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:)
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.
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 somethings 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.
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.
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.
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.
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)
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.
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.
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.
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.
If backward compatibility is not required, then OpenBSD's doas[0] may be a suitable alternative. Someone[1]'s ported it to other UNIX-like systems, though I don't know how good the port is.
The problem is that sudo is an attempt to hack around the piss-poor Unix security model. Doing the same in a different language will hit the same fundamental problems.
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.