Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sudo vulnerability

openwall.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Sudo vulnerability

#11

Post by yjftsjthsd-h »

newnewpdro wrote: post #5

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…

Yeah, I started using OpenBSD's doas and it's surprising how many things expect sudo specifically.

Re: Sudo vulnerability

#12

Post by AdmiralAsshat »

tyingq wrote: post #3

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. Some others: https://www.sudo.ws/other.html

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.

Re: Sudo vulnerability

#13

Post by jean23 »

newnewpdro wrote: post #5

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…

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.

Re: Sudo vulnerability

#14

Post by bad-joke »

svnpenn wrote: post #9

No date at all in the article. It helps to have that for context.

That confused me too. Internet Archive has earliest at 10/17/2019[1] and the page contains a link[2] to the Sudo team security alert on 10/14/2019.

[1] https://web.archive.org/web/20191017233613/https://resources... [2] https://www.sudo.ws/alerts/minus_1_uid.html

Re: Sudo vulnerability

#15

Post by breadandcrumbel »

bad-joke wrote: post #14
svnpenn wrote: post #9

No date at all in the article. It helps to have that for context.

That confused me too. Internet Archive has earliest at 10/17/2019[1] and the page contains a link[2] to the Sudo team security alert on 10/14/2019. [1] https://web.archive.org/web/20191017233613/https://resources... [2] https://www.sudo.ws/alerts/minus_1_uid.html

Does Web Archive screenshoot all the webpages out-there every day? If there is few days gap between each site screenshoot it might be the answer

Re: Sudo vulnerability

#18

Post by gregoryl »

breadandcrumbel wrote: post #10
kdbg wrote: post #8

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) 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 sendi…

You should be safe to assume anyone sitting in a lead role should be very comfortable with negative feedback, I'd not stress.

Re: Sudo vulnerability

#19

Post by slovenlyrobot »

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.

Re: Sudo vulnerability

#20

Post by fortran77 »

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.

Post reply on HN