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

41–50 of 60 posts

Re: Sudo vulnerability

#41

Post by iancarroll »

mehrdadn wrote: post #32
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.

How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.

Re: Sudo vulnerability

#43

Post by minitech »

iancarroll wrote: post #41
mehrdadn wrote: post #32

Earlier quoted context omitted.

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

How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.

Which UAC bypasses have they refused to fix?

Re: Sudo vulnerability

#44

Post by marcan_42 »

asveikau wrote: post #24
fortran77 wrote: post #21

How can bugs like this be prevented? Is Linix/Unix "sudo" security model simply flawed?

Not rust, but the OpenBSD folks wrote doas(1). 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.

Re: Sudo vulnerability

#45

Post by mehrdadn »

minitech wrote: post #43
iancarroll wrote: post #41

Earlier quoted context omitted.

How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.

Which UAC bypasses have they refused to fix?

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.

[1] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...

Re: Sudo vulnerability

#46

Post by johnisgood »

minitech wrote: post #43
iancarroll wrote: post #41

Earlier quoted context omitted.

How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.

Which UAC bypasses have they refused to fix?

I have no idea what he is referring to but being able to "Run as Administrator" as any user is sketchy.

Re: Sudo vulnerability

#47

Post by newnewpdro »

jean23 wrote: post #13
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…

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

Re: Sudo vulnerability

#50

Post by nray »

mehrdadn wrote: post #32
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.

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

Post reply on HN