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

121–130 of 328 posts

Re: Heap-based buffer overflow in Sudo

#121

Post by tbrownaw »

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…

> 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 PR does not include tests" is not the same as "nobody performed any tests" is not the same as "nobody actually noticed a bug".

And of course, it's perfectly reasonable to form beliefs about code from reading it.

Re: Heap-based buffer overflow in Sudo

#122

Post by ddevault »

saagarjha wrote: post #114
ddevault wrote: post #106

Earlier quoted context omitted.

>helps that a 10kloc c program getting riir'd probably won't be a 10kloc rust program, because c doesn't have libraries and rust does. What? Rust has so few libraries of significance that it still depends on C for security-critical areas like SSL. >it is literally impossible to write "a small codebase focused on its key value-adds without distractions" in a language that doesn't have strings and requires you to build…

Having written dictionary implementations in C, I would be very interested in seeing your implementation that fits in two dozen lines of code.

Threw together an example (untested, with obvious errors) to give you an idea of what it could look like:

https://paste.sr.ht/~sircmpwn/3122d4a27a8e5312462e2329bf7ed6...

Actually managed to get it to exactly 2 dozen lines of code, not including the header, which isn't bad for an off-the-cuff remark.

You'd naturally expand or shrink this with whatever subset of map functions you require, like key/value enumeration, object deletion, resizing, whatever. It depends on your use-case. I don't believe in generic code.

Re: Heap-based buffer overflow in Sudo

#123

Post by staticassertion »

ddevault wrote: post #99
staticassertion wrote: post #97

Earlier quoted context omitted.

A lot of your statements are pretty strong, and imo totally incorrect. > Complexity breeds bugs, including security bugs, and memory safety doesn't change that. Yes, memory safety changes that radically. > A simpler program will generally be more secure than a complicated one, no matter what language either is written in. Disagree, but the statement is really weak anyways, especially since 'complexity' is an ill-defi…

>Disagree, but the statement is really weak anyways, especially since 'complexity' is an ill-defined term. More features? Cyclomatic? I'm not sure of any definition of complexity you could appeal to which makes my argument weak. >>rewriting an established program from one language to another will always introduce more bugs than it fixes, and more severely the more complex the program is. >Should be obvious to anyone…

Yeah I think that's an absurd reduction. Rewriting code means that you can solve fundamental architectural issues, that you can start fresh with better tooling, that you have the lessons learned without the technical debt, etc.

Re: Heap-based buffer overflow in Sudo

#124

Post by statquontrarian »

How does this story not have a billion upvotes? HN should introduce sticky posts just for this bug and keep it at the top of the homepage for weeks.

> exploitable by any local user [...] without authentication

> introduced in July 2011 [...] in their default configuration

> full root privileges

Re: Heap-based buffer overflow in Sudo

#125

Post by tbrownaw »

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.

Re: Heap-based buffer overflow in Sudo

#126

Post by cpncrunch »

jwilk wrote: post #47
nickweb wrote: post #41

Is it normal for a security issue of this magnitude to have a 12 day notification period for everyone? That seems... short.

Yes. This was coordinated on the distros mailing list, which has maximum embargo period of 14 days, with periods shorter than 7 days preferable: https://oss-security.openwall.org/wiki/mailing-lists/distros...

Still no update for Centos 8, so I'm not sure that worked too well.

Re: Heap-based buffer overflow in Sudo

#127

Post by ddevault »

staticassertion wrote: post #123
ddevault wrote: post #99

Earlier quoted context omitted.

>Disagree, but the statement is really weak anyways, especially since 'complexity' is an ill-defined term. More features? Cyclomatic? I'm not sure of any definition of complexity you could appeal to which makes my argument weak. >>rewriting an established program from one language to another will always introduce more bugs than it fixes, and more severely the more complex the program is. >Should be obvious to anyone…

Yeah I think that's an absurd reduction. Rewriting code means that you can solve fundamental architectural issues, that you can start fresh with better tooling, that you have the lessons learned without the technical debt, etc.

Yeah, but why the assumption that those things are an issue? We're talking about mature codebases. Rewriting it again in C would also give you a chance to start fresh with better tooling, lessons learned, paying back tech debt, etc. Even still, you're going to introduce new bugs in the process. You might fix a few hard-to-address architectural issues, but all of the other bugs would be easier to fix in the original codebase than by rewriting the whole thing.

I'm not saying that a rewrite is never justified, but rather that the argument that we should rewrite in Rust simply to avoid bugs has little weight.

Re: Heap-based buffer overflow in Sudo

#128

Post by ddevault »

gpm wrote: post #118
ddevault wrote: post #100

Earlier quoted context omitted.

Aye, I agree. But if we consider that case, a similar mistake could be made: hard-coding argv[0]. The result is different, in that the program just aborts, but it's still the Wrong Thing To Do, and in both cases it never leads to anything exploitable. Bugs are bugs, no matter what language. We could come up with examples all day. Just head to your nearest Rust program's bug tracker :)

Aborting when argv[0] doesn't exist... is a perfectly reasonable thing to do? Someone called the program with arguments severely out of spec, crashing is fine.

It's actually within spec, in this case. Still reasonable?

Re: Heap-based buffer overflow in Sudo

#129

Post by arp242 »

rincebrain wrote: post #79
DaiPlusPlus wrote: post #73

Earlier quoted context omitted.

How is it possible that GNU’s `sudo` is not GPL? Unless it’s BSD, I guess?

It's not GNU's `sudo`, it's under an ISC-style license, and is maintained by an OpenBSD developer, so it's closer to "BSD's sudo" (though OpenBSD has been shipping `doas` instead for a little while now).

sudo even predates GNU by several years.

Re: Heap-based buffer overflow in Sudo

#130

Post by ddevault »

gautamcgoel wrote: post #120
ddevault wrote: post #42

Earlier quoted context omitted.

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…

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).
Post reply on HN