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

31–40 of 60 posts

Re: Sudo vulnerability

#31

Post by dang »

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…

Ok, we've changed the URL to that from https://whitesourc.com/new-vulnerability-in-sudo-cve-2019-14.... Thanks!

Re: Sudo vulnerability

#32

Post by mehrdadn »

slovenlyrobot wrote: post #19

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 "…

> 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.

Re: Sudo vulnerability

#33

Post by throwaway2048 »

slovenlyrobot wrote: post #19

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 "…

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.

https://man.openbsd.org/doas

Re: Sudo vulnerability

#34

Post by tomrod »

yjftsjthsd-h wrote: post #11
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.

For the most part, could you alias doas to sudo?

Re: Sudo vulnerability

#35

Post by gilgamesh3 »

throwaway2048 wrote: post #33
slovenlyrobot wrote: post #19

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 "…

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. https://man.openbsd.org/doas

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.

[0] https://github.com/multiplexd/doas

[1] https://github.com/slicer69/doas

Re: Sudo vulnerability

#36

Post by marcan_42 »

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.

Re: Sudo vulnerability

#38

Post by earenndil »

throwaway2048 wrote: post #33
slovenlyrobot wrote: post #19

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 "…

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. https://man.openbsd.org/doas

Doas is very nice. I would like to use it on linux, but it only supports credential caching on openbsd.

Re: Sudo vulnerability

#39

Post by jlgaddis »

isostatic wrote: post #22
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…

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 wha…

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).

Re: Sudo vulnerability

#40

Post by jlgaddis »

tomrod wrote: post #34
yjftsjthsd-h wrote: post #11

Earlier quoted context omitted.

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

For the most part, could you alias doas to sudo?

FWIW, I did exactly that on my OpenBSD machines when doas was first introduced and I can't think of any issues I've encountered.
Post reply on HN