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

Heap-based buffer overflow in Sudo

qualys.com

Post reply on HN
Print view View original

281–290 of 328 posts

Re: Heap-based buffer overflow in Sudo

#281

Post by tbrownaw »

tgbugs wrote: post #192
tbrownaw wrote: post #125

Earlier quoted context omitted.

> Despite this, the wisdom of the crowd is that you should never su to root, for ... reasons? `su` takes the password of the user you're becoming, while `sudo` takes the password (or not) of the user you already are. So using `su` to become root implies that there's a root password that multiple people (well, assuming there's multiple admins on the box) know.

I firmly agree that sharing passwords is bad, however I can't imagine a threat model where password sharing among multiple parties is more risky than giving multiple people sudo. As zests points out, practically there is no difference because anyone with sudo can change the root password, they are already root, so the auditing use cases is moot if the logging system can't distinguish between two users sudo sued into…

> I can't imagine a threat model where password sharing among multiple parties is more risky than giving multiple people sudo

An individual leaves the company and the security / compliance people say all their access to be revoked, which is kind of a headache with shared logins.

The security / compliance people want audit logs of who does what, which is harder to do with shared logins.

I think both of these things are encouraged (maybe required?) by various certifications that companies doing certain things might need.

Re: Heap-based buffer overflow in Sudo

#282

Post by JoachimS »

Someone wrote: post #246
arp242 wrote: post #152

Earlier quoted context omitted.

Maybe expecting projects that mostly consist of a single guy working on it in their spare time to be "NSA proof" isn't really realistic? Folk love to bring up "responsibility" and all of that, but you can't really expect people to bear the responsibility of the world on their shoulders for their spare time projects. It's neither realistic nor fair.

No, you can’t. I think the blame shouldn’t be on this author, but on those choosing to install it or, worse, choosing to ship it on their OS. OpenBSD replaced sudo with doas ( http://man.openbsd.org/doas ) in 2016 ( https://www.infoworld.com/article/3099038/openbsd-60-tighten... ). It’s a safe bet it’s more secure than sudo .

doas is a a really good replacement.

Re: Heap-based buffer overflow in Sudo

#283

Post by duncaen »

cyounkins wrote: post #228

What variant of `doas` do people run as an alternative? I see Duncaen/OpenDoas, slicer69/doas, multiplexd/doas on GitHub. None seem super widely used as judged by watches/stars/forks.

I would say that the concept and implementation in C is inherently insecure. Switching to something less reviewed because there is a sudo vulnerability is not a guarantee that you are now "safer" especially if those ports are not reviewed.

As far as I can say, never ever use slicer69/doas, I've found 3 critical security vulnerabilities in it, the author does not understand C or how it should work in general.

Here are 3 examples if issues I found and the author used misleading commit titles to hide the issues and made excuses saying a clear buffer overflow very similar to the one found in sudo is just "potential":

- https://github.com/slicer69/doas/commit/261c2164496dbebe6e3e...

- https://github.com/slicer69/doas/commit/2f83222829448e5bc4c9...

I even had to do a PR myself to fix an issue the author was not able to understand and more and more people started to use it:

- https://github.com/slicer69/doas/pull/23

Re: Heap-based buffer overflow in Sudo

#284

Post by igneo676 »

gerdesj wrote: post #176
jeffbee wrote: post #57

All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested. The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change. The pull request that supposedly fixes this CVE also includ…

"All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested" Fair enough but what do you recommend? Me, I try to keep people out of my systems that I don't trust. This particular snag needs local access but I will grant you that my web server or other exposed service might provide a local interface. Instead of throwing your hands up and screaming "crap" you do your…

In short: There's nothing that you can do

Longer: One of two things -

1. Choose the most boring software possible, trust that the process will work as expected and that you're no worse off than anyone else. Update your software regularly

2. Choose the simplest, most robust software possible (Alpine, OpenBSD, etc). In this case, doas instead of sudo. Pray that works better than everyone else or that you get some benefits through obscurity. Still get surprised every so often. Update regularly

Either way, modern software has gotten complex enough that there's few options for the average person

Re: Heap-based buffer overflow in Sudo

#285

Post by cpncrunch »

ilikejam wrote: post #280
cpncrunch wrote: post #218

Earlier quoted context omitted.

I hadn't heard of Qualys until today, and am very unhappy with them. They have thrown us all under the bus by releasing details of this vulnerability before updates are available for major distros. (Still no update for Centos 8 at time of writing this, not sure about any others).

RedHat built the fixed sudo RPMs 5 days ago.

They only released it yesterday:

https://access.redhat.com/security/cve/CVE-2021-3156

Still nothing on Centos. Perhaps just another reason to not trust Redhat.

Re: Heap-based buffer overflow in Sudo

#286

Post by greggyb »

Someone wrote: post #246
arp242 wrote: post #152

Earlier quoted context omitted.

Maybe expecting projects that mostly consist of a single guy working on it in their spare time to be "NSA proof" isn't really realistic? Folk love to bring up "responsibility" and all of that, but you can't really expect people to bear the responsibility of the world on their shoulders for their spare time projects. It's neither realistic nor fair.

No, you can’t. I think the blame shouldn’t be on this author, but on those choosing to install it or, worse, choosing to ship it on their OS. OpenBSD replaced sudo with doas ( http://man.openbsd.org/doas ) in 2016 ( https://www.infoworld.com/article/3099038/openbsd-60-tighten... ). It’s a safe bet it’s more secure than sudo .

Sudo was (maybe still is?) an OpenBSD project. I don't believe it originated there, but their code forms/formed the basis for sudo pretty much everywhere, much like OpenSSH.

Re: Heap-based buffer overflow in Sudo

#287

Post by 0xbadcafebee »

MayeulC wrote: post #265
0xbadcafebee wrote: post #202

Earlier quoted context omitted.

If sudo were written in Perl, it would also not be vulnerable.

I thought about that. But when using a higher-level language (that comes with a runtime), you need to give privileges to the whole runtime, which arguably has a much bigger attack surface, unless I am mistaken? The kernel won't allow you to setuid scripts, there is a reason for this: it's very easy to leave glaring security holes while doing so.

Perl had a fix for this called suidperl, which was a wrapper which enabled Taint mode and other strict checks (https://perldoc.perl.org/perlsec). I don't know of any other language or interpreter that go this far for security by default, so Perl might be the most secure language in this regard. However, suidperl was dropped in 5.12.

My main point was that you could rewrite sudo in all sorts of languages, but saying "just rewrite it in Perl" (assuming it worked) isn't a enough justification to make it happen. Nobody is going to re-create their own project in Perl, Rust, etc just to eliminate buffer overflows. If somebody wants sudo in Rust, they'll have to do it themselves, and it still might never replace the original.

Re: Heap-based buffer overflow in Sudo

#288

Post by swsieber »

joveian wrote: post #268
roca wrote: post #171

Earlier quoted context omitted.

From the point of view of bugginess, complexity in the implementations of massively popular libraries is far less of an issue than code you just wrote yourself, because the code in those libraries will have received much more testing than the code you just wrote yourself. So it doesn't really make sense to just add the complexity of components up like that.

sudo is quite a popular utility, by the same logic it might be expected to be well tested...

Yes. And I shudder to think just how many bugs there would be in a home-grown sudo replacement.

Re: Heap-based buffer overflow in Sudo

#289

Post by JoachimSchipper »

eklitzke wrote: post #252
megous wrote: post #162

Earlier quoted context omitted.

PAM is fun. https://github.com/systemd/systemd/issues/16813 With all the .so modules loading into some process, etc. Some questionable design in sshd makes it lock up completely for all incoming connections when used with PAM and when pam module ends up in infinite loop. Nevermind that systemd pam modules pull in a shitton of stuff, including dbus, into any process that tries to use PAM for auth, these days. I guess…

How else would you implement PAM? The whole point is that you can write arbitrary code to implement whatever custom authentication policy you have, so it needs to be able to dlopen things. And if you don't like the PAM policy written by your distro, you're free to change it by implementing your own authentication policies, or dropping things you don't care about (like systemd, you can configure PAM to just use /etc/p…

https://man.bsd.lv/login.conf.5#AUTHENTICATION documents OpenBSD's system, which revolves around running /usr/libexec/auth/login_. OpenBSD's system doesn't let you do the stack-of-libraries thing that PAM does, but having one binary is a lot simpler.

(In the past, OpenBSD had a login-locally-or-via-Kerberos binary there, which does show the downside of that approach over PAM's more flexible approach.)

Post reply on HN