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

51–60 of 328 posts

Re: Heap-based buffer overflow in Sudo

#51

Post by mulmen »

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…

Fair point re: complexity but how are CVEs in one codebase evidence of absence of bugs in another?

Or said another way, is the lack of CVEs for doas an indication it is more secure or just less (ab?)used?

Re: Heap-based buffer overflow in Sudo

#52

Post by wahern »

turminal wrote: post #48
wahern wrote: post #13

Earlier quoted context omitted.

doas is just OpenBSD. You can install doas from ports on NetBSD or FreeBSD, just like you can install doas on Linux. OpenBSD dropped sudo from the base OS several years ago. sudo just became too complex, tailored to the feature creep demanded and required (PAM, ugh ) by Linux users.

Briefly going through their website (sudo.ws) I am seriously wondering why anyone would want to put some of those features in a privilege management tool.

Todd Miller is a sharp developer and core OpenBSD contributor. I can only imagine the deluge of requests and pressure he faces to expand sudo. There's no end to the crazy stuff corporations demand, especially when it comes to integration--audit, logging, ldap, etc.

Re: Heap-based buffer overflow in Sudo

#55

Post by zamadatix »

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…

If you go a little further with the quote:

"Yes, it would still be vulnerable to logic errors... But it wouldn't be vulnerable to this. "

I think you'll find in disagreeing with the comment on logic errors you just said the same thing the comment did about logic errors.

Also I think the generalization that rewriting an established bit of code in a new language in a secure language is a bit too general. clearly Firefox not only set out to make Rust for this purpose but it's not had an explosion in vulnerabilities with the modules it has replaced. Quite the opposite actually. Nor has every tool or app rewritten become a security failure compared to the original. I do think it's something that can easily be screwed up though, especially if someone rushes through by focusing on functionality duplication instead of building a more secure version of something.

Regardless, both "using a memory safe language results in a more safe program" and "having a minimum attack sufrace results in a more safe program" can be true. There is no need to make it a choice of A or B.

Re: Heap-based buffer overflow in Sudo

#56

Post by pjmlp »

eqvinox wrote: post #29
pjmlp wrote: post #25

Earlier quoted context omitted.

I have been advocating against C since comp.lang.c days, no need for lessons about how to market something that the audience obviously isn't interested into paying attention. The first systems programming language that would prevented this kind of exploit was written in 1961, 10 years before C was invented.

Neither of these is an excuse for the condescending, snarky tone. [Ed.: Actually, the tone is probably a factor in the audience not being interested.] [Ed. 2: https://news.ycombinator.com/item?id=21490714 ]

As usual in everything tech related, it depends.

Re: Heap-based buffer overflow in Sudo

#57

Post by jeffbee »

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 includes no tests. There is no reason anyone should believe this fix is effective or complete, or that it does not introduce new defects. This is the result of people who stubbornly refuse to practice even the most basic good engineering practices, like testing and code review, while at the same time using the industry's most dangerous high-level language. As long as this type of thing continues, our tools will remain at a very low level of safety, reliability, and correctness.

Re: Heap-based buffer overflow in Sudo

#58

Post by rootsudo »

bitwize wrote: post #19
cab404 wrote: post #16

Never knew sudo had a site ( https://sudo.ws ). Never knew it had a mascot, if you could call it so... I will never unsee it. Nightmare fuel at it's finest.

Oh my God, it's a reference to the "sudo make me a sandwich" XKCD on top of it all.

That's the best, I didn't/couldn't believe it, but it's true.

This made my day. God it is scary.

Re: Heap-based buffer overflow in Sudo

#59

Post by nsajko »

pjmlp wrote: post #12
nahuel0x wrote: post #6

"rewrite sudo in Rust" in 3,2...

Why? After all it is obvious code reviewers are enough to catch any typical C memory corruption error.

Firstly, the constant nagging (of the kind appearing here, and often on other HN threads) against C and family are obnoxious. Any language will have both downsides and upsides and picking this one "flaw" in C and then pretending like it's a reason that C absolutely shouldn't be used is absurd.

Secondly, the Sudo code in question seems to be a result of a poor or nonexistent design process (which also seems consistent with Sudo's horrific bloat of features), so this isn't a good example for preaching against C.

Slightly off-topic, but FTR I view C as somewhat crippled and C++ as an easy to misuse Lovecraftian monstrosity (but much more powerful and useful than C), and I suspect Rust's way of forbidding the user from making memory errors is more trouble than it's worth.

Re: Heap-based buffer overflow in Sudo

#60

Post by ddevault »

zamadatix wrote: post #55
ddevault wrote: post #49

Earlier quoted context omitted.

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

If you go a little further with the quote: "Yes, it would still be vulnerable to logic errors... But it wouldn't be vulnerable to this. " I think you'll find in disagreeing with the comment on logic errors you just said the same thing the comment did about logic errors. Also I think the generalization that rewriting an established bit of code in a new language in a secure language is a bit too general. clearly Firefo…

>I think you'll find in disagreeing with the comment on logic errors you just said the same thing the comment did about logic errors.

I think you'll find that my comment explicitly acknowledges this and expands on it with another example. Are we done telling each other to read the things we're writing?

>Firefox not only set out to make Rust for this purpose but it's not had an explosion in vulnerabilities with the modules it has replaced.

You're setting the bar pretty high with an "explosion" of vulnerabilities here. Rust programs have vulnerabilities, including rewrites. They also have other kinds of bugs, often ones which were not present in the code that they're replacing. You need only browse your nearest convenient RiiR bug tracker to find evidence of this.

Let me restate my thesis in mathematical terms. If we presume that 1 in 100 lines of production code has a bug in it, regardless of language (generous, I know), and that 1 in 10 bugs in C programs are memory corruption related, then saving 10% of those bugs by rewriting it in Rust would take a 10,000 line codebase from 100 bugs to 90 bugs. A 1,000 line codebase, still written in C and without the advantage of memory safety, would have only 10.

In today's example, sudo is a caricature of runaway complexity. Rust is often touted as a panacea, but C has very little to do with why sudo is insecure. Sudo is comically overengineered and that level of overengineering has no place in a security context. This is the larger issue that needs to be addressed, not Rust.

Post reply on HN