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

21–30 of 60 posts

Re: Sudo vulnerability

#22

Post by isostatic »

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 what they did. Far more useful than "joebloggs went to root at 03:14 and logged out at 09:15"

Re: Sudo vulnerability

#23

Post by asveikau »

gregoryl wrote: post #18
breadandcrumbel wrote: post #10

Earlier quoted context omitted.

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.

It would be nice to imagine the world as it should be, but I don't think this is actually super common.

Re: Sudo vulnerability

#24

Post by asveikau »

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.

Re: Sudo vulnerability

#25

Post by nkozyra »

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.

> Also I am not sure how rust solves this bug

Giving the benefit of the doubt I think this was in jest

edit: comment history confirms

Re: Sudo vulnerability

#26

Post by RJIb8RBYxzAMX9u »

fortran77 wrote: post #21

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

If backward compatibility is not required, then OpenBSD's doas[0] may be a suitable alternative. Someone[1]'s ported it to other UNIX-like systems, though I don't know how good the port is.

[0] https://man.openbsd.org/doas

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

Re: Sudo vulnerability

#28

Post by rodgerd »

fortran77 wrote: post #21

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

The problem is that sudo is an attempt to hack around the piss-poor Unix security model. Doing the same in a different language will hit the same fundamental problems.

Re: Sudo vulnerability

#29

Post by aquabeagle »

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.

Fun fact: sudo is maintained by an OpenBSD developer
Post reply on HN