Sudo vulnerability
openwall.com
openwall.com
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.
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.
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.
[1] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...
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.
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.
_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.
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'`
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.
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.
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"
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.
Some others: https://www.sudo.ws/other.html
> 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.
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.
[1] https://web.archive.org/web/20191017233613/https://resources... [2] https://www.sudo.ws/alerts/minus_1_uid.html
Date: Mon, 14 Oct 2019 09:00:31 -0600https://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.
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.
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.
Giving the benefit of the doubt I think this was in jest
edit: comment history confirms
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.
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.