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

81–90 of 328 posts

Re: Heap-based buffer overflow in Sudo

#81

Post by ddevault »

comex wrote: post #71
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…

Incidentally, after inspecting doas for a few minutes, I found two near-vulnerability bugs in it. The first bug lets any user cause doas to read out of bounds of an array, though not in a way that's exploitable. Well, it's arguably a bug in libc. If you run doas with a completely empty argv (argc = 0, so not even an executable name; the two systems I tried, Linux and macOS, both let you do this), getopt will exit wit…

Nice finds. I would agree that that's more arguably a bug in libc than in doas, but also note that the startup code for any language has to consider this case. As far as theoretical operating systems are concerned, this is a consequence of the System-V ABI, so any OS compatible with it would have the same issue.

As for the integer overflow case, it's also highly unlikely to be exploitable, even if it were unsigned - the system would have to, as I'm sure you can infer, have tens of millions of rules before this was an issue. It's quite within the realm of reason, in my opinion, to declare this an acceptable trade-off. The rest of your explanation shows that even if this weren't the case, the bug wouldn't be exploitable.

Anyway, I like your comment, but I'd recommend a different moral to this story: in the space of 47 minutes you were able to conduct a reasonably thorough audit on the doas codebase. Wanna give that a shot for sudo now?

Re: Heap-based buffer overflow in Sudo

#83

Post by megous »

wahern wrote: post #10
megous wrote: post #3

One of those programs that you should not install unless you really need them.

Not sure if you were being sarcastic, but OpenBSD removed sudo several years ago. The native tool is doas: https://man.openbsd.org/doas sudo just became too complex, what with the feature creep demanded by corporate Linux users.

Not sarcastic. SUID root binaries are a prime target for hackers, and even I've used them to gain local privilege escalation in the past. For example authors of VEGA5000 payment terminal made pppd used for GPRS internet connection have a suid root permissions, and pppd can be used to execute other programs just based on the command line arguments. So that was that.

sudo looks quite complicated, just by looking at what it has to parse and validate (sudoers file). I'd rather not have it on the server, and just use custom purpose made static built suid binaries for necessary minimal purposes of privilege granting.

It's not even installed by default on some popular Linux distros. Of course I realize that it's very ubiquitous, regardless of this. And it's probably fine to use on your workstation. But leaving it unattended on some server feels a bit dreadful.

Re: Heap-based buffer overflow in Sudo

#84

Post by cbarrick »

DaiPlusPlus wrote: post #73
jeffbee wrote: post #67

Earlier quoted context omitted.

The GNU project is wall-to-wall toxic waste, but I note for the record that I don't think sudo is a GNU program and IIRC it's not even GPL.

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

There is no such thing as GNU sudo.

The homepage for sudo is https://www.sudo.ws/

It is licensed under an ISC style license.

Re: Heap-based buffer overflow in Sudo

#85

Post by yread »

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.

Hmm the year is wrong on the timestamps. Attention to detail is important in C programmers working on security critical software...

Re: Heap-based buffer overflow in Sudo

#86

Post by ddevault »

vitno wrote: post #75
ddevault wrote: post #60

Earlier quoted context omitted.

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

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 made and already fixed in the original codebase. If you're rewriting it from scratch, can you be sure you won't make just as many? A stable, maintained codebase with a low throughput of changes tends to have fewer bugs over time, as the lack of churn avoids introducing new bugs and the application of time susses out all of the existing bugs. Rewriting the whole thing from scratch has a very high rate of churn, introducing a whole new slew of bugs on its own.

Now, a small codebase, focused on delivering its key value-adds without distractions, kept stable and at a low-churn rate over a long period of time: no matter what language you use, this is the best recipe for reliability and security.

Re: Heap-based buffer overflow in Sudo

#87

Post by ddevault »

arp242 wrote: post #72
ddevault wrote: post #62

Earlier quoted context omitted.

Adding features because they solve a specific use-case is grossly irresponsible. Solving a specific use-case is only one of many criteria that needs to be met for a feature to be justified. Others include "is it in scope?", "is it a maintenance burden?", "does it make existing features more unreliable?", "will its bugs affect people who don't need it?", "can it be done in a separate tool?" Anyone can come up with a u…

sudoedit is used by many people, and setting a different shell with -s seems like something that would cover a number of edge cases, yes, but writing a new tool just to add "-s" is obviously silly. Nothing in this particular CVE touches on anything that seems particularly obscure to me. The last major sudo bug was in the PAM code (which lead to the creation of doas), which is something many people don't need, but als…

For what it's worth, PAM is also not invited to my parties, for all of the same reasons as sudo was shown the door. And what people want PAM for is mostly solved with SSH certificates.

>writing separate tools would be the equal (or more!) lines of code and an equal amount of bugs in total

In total, yes, but crucially, not all on your system at the same time.

Re: Heap-based buffer overflow in Sudo

#88

Post by toyg »

im3w1l wrote: post #78
miohtama wrote: post #64

Earlier quoted context omitted.

Another question is who wants to maintain four decades old GNU C soup? It was written at a different time, with different best practices. In some point someone will rewrite all GNU/UNIX user land in modern Rust or similar and save the day. Until this happens these kind of incidents will happen yearly.

Rewriting sudo is a weekend project*. Getting people to adopt it is a many-year political campaign.

You can bet your last dollar that if the "right" RedHat or Debian developer rewrote sudo with feature parity, it would be adopted by all major distros in a couple of months. It's the sort of thing nobody really cares about except OpenBSD (which wrote their own).

The problem is feature parity. Most rewrites cannot guarantee that off-the-bat, so they end up struggling to persuade people to switch - why break stuff that works just fine and lose features, in the name of some engineering purity?

Re: Heap-based buffer overflow in Sudo

#89

Post by bnroberts »

jeffbee wrote: post #74
muricula wrote: post #70

Earlier quoted context omitted.

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.

You can bet your bottom banana that the GRU, the NSA, Chinese state security, and the mob have all thoroughly fuzzed sudo and are sitting on the results. It just seems SO EASY to add a test for this problem, literally the relevant test input is one slash by itself, or any string ending in a slash! So simple! If I sent a change like this at work, no matter how trivial, that said it fixed this bug but I didn't send any…

Single persons often have superhuman standards. It is easy to see that most of the best works in math or art were produced by an individual.

Code review can work, but often it doesn't. There are countless examples of projects with "strict" review requirements that have similar issues (whereas qmail only had one).

Writing tests is the important thing, it keeps you honest.

Re: Heap-based buffer overflow in Sudo

#90

Post by jeffbee »

bnroberts wrote: post #89
jeffbee wrote: post #74

Earlier quoted context omitted.

You can bet your bottom banana that the GRU, the NSA, Chinese state security, and the mob have all thoroughly fuzzed sudo and are sitting on the results. It just seems SO EASY to add a test for this problem, literally the relevant test input is one slash by itself, or any string ending in a slash! So simple! If I sent a change like this at work, no matter how trivial, that said it fixed this bug but I didn't send any…

Single persons often have superhuman standards. It is easy to see that most of the best works in math or art were produced by an individual. Code review can work, but often it doesn't. There are countless examples of projects with "strict" review requirements that have similar issues (whereas qmail only had one). Writing tests is the important thing, it keeps you honest.

31 CVEs later I think it's safe to say that this particular author does not possess superhuman standards. How much more evidence would we need?
Post reply on HN