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

181–190 of 328 posts

Re: Heap-based buffer overflow in Sudo

#181

Post by nsajko »

tbrownaw wrote: post #125
tgbugs wrote: post #112

Yet another vindication for one of my long-standing practices. I try to avoid installing sudo at all cost on my systems because all it does is increase the attack surface. Despite this, the wisdom of the crowd is that you should never su to root, for ... reasons? Fat fingering is a thing, but if you can accidentally be in a root terminal without realizing it you have done something horribly wrong. Heck, from a certai…

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

If a system is configured as you describe, that just means that it then effectively has an additional root/admin account, except under a possibly unpredictable name. So security through obscurity, really (if the privileged user name is secret). That might make sense for some small number of setups, but instead it seems to be enormously popular, and often times it is even used in the security-defeating manner of having the "usual" user be privileged.

Re: Heap-based buffer overflow in Sudo

#182

Post by gautamcgoel »

ddevault wrote: post #130
gautamcgoel wrote: post #120

Earlier quoted context omitted.

Hi Drew, I agree with everything you said re complexity and rust. What we really need is a modernized C language, tools that help us catch bugs like this, and a better culture of testing and accountability. I'm curious whether you run OpenBSD, since you mentioned you use doas. Do you have any thoughts on OpenBSD?

I don't run OpenBSD, for reasons that have little to do with security. In my opinon, OpenBSD is not agressive enough at complexity reduction (doas being an outlier, I think doas is quite a good size).

I see. What do you run, if you don't mind me asking?

Re: Heap-based buffer overflow in Sudo

#183

Post by syngrog66 »

this doesnt surprise me

a few years ago I found a flaw in sshd. because it was impacting a Linux PAM login/auth module I was writing in C. my module should have worked. but it wasnt. because of sshd. it blew me away, given how important that server is. luckily, others must have complained too, and it ended up being fixed in a newer sshd release. but the fact that it made it into a release in the first place, impacting PAM, was scary

on a not-totally-unrelated note, that was also the last C project I wrote, and since then I fell in love with Go and Rust. for systems code, for me, theres no going back. C is scary given the modern threat ecosystem and whats at stake

Re: Heap-based buffer overflow in Sudo

#184

Post by jodrellblank »

ddevault wrote: post #49
comex wrote: post #45

Earlier quoted context omitted.

But if sudo were written in Rust, it could have the same level of complexity and not be vulnerable. Yes, it would still be vulnerable to logic errors, like the last famous sudo bug where you pass -1 as the UID. But it wouldn't be vulnerable to this. (And this isn't the first memory safety bug to be found in sudo.) Yes, sudo's complexity is useless for 99.99% of its users. But wouldn't it be nice if the result were me…

>But if sudo were written in Rust, it could have the same level of complexity and not be vulnerable. This is not true. Complexity breeds bugs, including security bugs, and memory safety doesn't change that. Your example is a good one - here's another: doas once failed to limit the environment variables which are passed to the child process, which could be used to nefariously influence the program running (e.g. with L…

> "Furthermore, rewriting an established program from one language to another will always introduce more bugs than it fixes"

Here[1] is a link to a slideshow of a talk on the F# language, with a case study from EON PowerGen company rewriting the core of an application evaluating revenue due from their balancing services contracts nationwide in the UK. It was originally 350,000 lines of C# developed by 8 people in 5 years and incomplete. It was redeveloped by 3 people (2 had never used F# before) in 30,000 lines, complete in 1 year.

They claim zero bugs in the F# redeveloped system (page 29). This example also gets a mention in a Don Syme (F# language designer) talk in 2018[2] with the PowerGen employee in the audience.

The PDF cites a testimonial from Kaggle saying they're moving more and more of their application into F# which is "shorter, easier to read, easier to refactor, and because of strong typing, contains far fewer bugs".

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

[2] https://www.youtube.com/watch?v=kU13g_noAQM

Re: Heap-based buffer overflow in Sudo

#185

Post by hsaliak »

ddevault wrote: post #42
MayeulC wrote: post #40

Memory safety strikes again, it seems (overflow in a C string due to complex parameter parsing rules).

No, complexity strikes again. I haven't used sudo in years, preferring to use doas now. Its essential code is less than 500 lines and it does everything I've ever used sudo for, and that includes much more than `sudo `. $ man doas | wc -l 58 $ man doas.conf | wc -l 101 $ man sudo | wc -l 741 $ man sudoers | wc -l 3254 And a bonus: $ man sudoers | grep -C1 despair The sudoers file grammar will be described below in Ex…

Don’t know why this comment is getting downvoted. The code in question is complex and outdated. Improving the code and testing or switching to simpler tools can lead to a pragmatic solution without the political baggage.

Re: Heap-based buffer overflow in Sudo

#186

Post by gnunez »

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…

A Turing Award winner once said, “Program testing can be used to show the presence of bugs, but never to show their absence!"

Re: Heap-based buffer overflow in Sudo

#187

Post by jodrellblank »

ddevault wrote: post #86
vitno wrote: post #75

Earlier quoted context omitted.

I agree Rust is not a panacea and that rewrites create their own set of problems, the only issue with this analysis is assuming 1/10 bugs are memory corruption related. Both Chrome & Microsoft found about 70% of bugs to be memory safety related. I've heard similar numbers out of FB as well. The math looks a little different with that data. https://www.chromium.org/Home/chromium-security/memory-safet... https://www.zd…

Even if we run the same math with 7 out of 10 bugs being memory safety related, and assuming that Rust prevents all of them, those same example programs end up with 30 bugs in Rust and 10 bugs in C. There's another argument I could make, too. Look at the bug tracker for the program you want to rewrite in Rust, examining the historical bugs. You'll find that there are often hundreds or thousands of mistakes that they…

> "Even if we run the same math with 7 out of 10 bugs being memory safety related, and assuming that Rust prevents all of them, those same example programs end up with 30 bugs in Rust and 10 bugs in C."

Maybe but not necessarily; it's reasonable to assume that Microsoft and FaceBook put non-zero effort into designing around, programming around, testing, looking for and fixing memory safety related issues in their C code. It could be the case that not having to care so much about those frees up some non-trivial amount of attention and time which could be spent on the other classes of problems.

Re: Heap-based buffer overflow in Sudo

#188

Post by comex »

gameswithgo wrote: post #160
comex wrote: post #45

Earlier quoted context omitted.

But if sudo were written in Rust, it could have the same level of complexity and not be vulnerable. Yes, it would still be vulnerable to logic errors, like the last famous sudo bug where you pass -1 as the UID. But it wouldn't be vulnerable to this. (And this isn't the first memory safety bug to be found in sudo.) Yes, sudo's complexity is useless for 99.99% of its users. But wouldn't it be nice if the result were me…

Rust would have prevented the -1 as a UUID too, because you would have used a sum type (Rust enums) instead of a sigil there. Its easier, its idiomatic, its more clear, and the compiler knows how to optimize the overhead away a lot of the time.

Well, in this particular case, the special behavior of -1 is baked into the setresuid system call, while sudo thought it was just an ordinary UID. So if you look at one of the Rust operating system projects designed from scratch from-scratch OS designs, it might not have this kind of pitfall. But if you literally just reimplement sudo for existing OSes in Rust – which I think would be a neat project for someone to take on – you’d be at risk of running into it.

Re: Heap-based buffer overflow in Sudo

#189

Post by acdha »

muricula wrote: post #70
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…

Even if there were basic unit & regression tests, this bug might not have been caught. This bug should have gone through detailed security review and should probably also undergo fuzzing.

We’d all like that, true, but look here:

https://github.com/sudo-project/sudo/graphs/contributors

That’s one maintainer, not even full time according to his résumé. What you just described is multiple specialists and some supporting tools, so another way of looking at this is to ask how much value the IT world has gotten from sudo but not contributed back in support.

When something is this widely used, it’s easy to forget that the answer to who should do more isn’t the one person who actually steps up to keep it alive.

Post reply on HN