Sudo vulnerability
openwall.com
Sudo vulnerability
1–10 of 60 posts
Re: Sudo vulnerability
#2For the curious, this is the patch that fixes it: https://www.sudo.ws/repos/sudo/rev/83db8dba09e7
Re: Sudo vulnerability
#3It'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
Re: Sudo vulnerability
#4Personally I'm amazed that this is only discovered today. Wink wink nudge nudge.
Re: Sudo vulnerability
#5Sudo 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'`
Re: Sudo vulnerability
#6I love the logo for Sudo
Re: Sudo vulnerability
#7Sudo 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…
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.
Re: Sudo vulnerability
#8The 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
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.
Re: Sudo vulnerability
#9No date at all in the article. It helps to have that for context.
Re: Sudo vulnerability
#10The 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 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 al…
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.