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

161–170 of 328 posts

Re: Heap-based buffer overflow in Sudo

#161

Post by gpm »

ddevault wrote: post #149
gpm wrote: post #142

Earlier quoted context omitted.

It's within the C and systemv abi specs, but it's not within the implicit contract of how you call command line programs. I'm fine with it.

Right, but if it was within the specs, possible to craft a scenario for, and leads to a security vulnerability, then does it suddenly matter? A bug is a bug. If it doesn't matter for Rust then it doesn't matter for C.

> and leads to a security vulnerability

I have trouble imagining how aborting leads to a security vulnerability? That's literally running no code, the opposite of running arbitrary code.

Aborting is fine in any language. Criticisms of C here would come about because C doesn't abort when it should (null pointer deref, array out of bounds, etc), not the inverse.

Re: Heap-based buffer overflow in Sudo

#162

Post by megous »

deckard1 wrote: post #145
kuschku wrote: post #105

Earlier quoted context omitted.

Polkit-exec (pkexec) already exists, has much better security, and integrates with your DE instead of expecting passwords on the terminal.

This thing? https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/s... Which also seems to not have tests. In fact, the only tests I'm seeing are from 2 years ago. https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/t... > has much better security It's using D-bus. My faith in D-bus security is close to my faith in seeing a fresh Linux install with zero D-bus error messages from apps. Which is to say, non…

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 it all runs as root, too. sshd at least tries to fork a child for all this and waits for it and kills it, so that the parent process can't be polluted. It just has no timeout when waiting for result, and doesn't accept further connections when waiting.

Sometimes it's better not to look too deep under the covers.

Re: Heap-based buffer overflow in Sudo

#163

Post by tinco »

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?

Rust is modernized C. You are looking for something that already exists. If C programmers would be looking for tools to help catch bugs like this and a better culture of testing and accountability they would be using Rust.

Re: Heap-based buffer overflow in Sudo

#164

Post by jrockway »

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 journey of a thousand releases begins with the first unit test.

Everyone has decided to stay home this year, though.

Re: Heap-based buffer overflow in Sudo

#165

Post by roca »

musicale wrote: post #95
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 I'm puzzled that we don't have a memory-safe ABI (e.g. amd64-safe) and runtime for C so we could just compile things with clang -safe sudo.c to avoid memory errors. I'm fine with sudo (or whatever) taking a 60% performance hit to be more reliable - processors are thousands of times faster now than they were in 1980 wh…

Encoding array bounds into fat pointers doesn't always work without changing code (e.g. code that uses funky casts, code that makes assumptions about data layout).

Also to ship this in a Linux distro you'd need two builds of many packages. Tons of tools would need to be updated to work with the new ABI. It would be a nightmare.

Furthermore, a new fat-pointer ABI would not address lifetime errors like use-after-free, so what would your plan be there? Boehm GC? More complexity, more overhead, more compatibility issues.

So in practice this is not that appealing, which is why we don't do it.

Re: Heap-based buffer overflow in Sudo

#166

Post by roca »

kaba0 wrote: post #146
roblabla wrote: post #132

Earlier quoted context omitted.

Compile it for wasm and use a wasm runtime built in a memory-safe language? I believe some wasm runtimes allow for making raw syscalls.

It would not stop these sort of exploits if I’m not mistaken (ok, it could help since rewriting return addresses is not possible I think), but memory errors that cause logic bugs are still possible.

Yes, that's exactly right.

Re: Heap-based buffer overflow in Sudo

#167

Post by megous »

umvi wrote: post #68
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.

> It was written at a different time, with different best practices. Not that I have any faith in modern "best practices". I'm imagining `grep` written in modern a modern language like JS and I shutter when I think of the hundreds of micro-dependencies like "left-pad" that would need to be downloaded to make it work. Maybe it's fair to say that systems programming languages are in a better state in terms of modern be…

I actually like some modern grep alternatives, like `ag`.

Re: Heap-based buffer overflow in Sudo

#168

Post by anthk »

young_unixer wrote: post #77
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.

> someone will rewrite all GNU/UNIX user land in modern Rust or similar Or everyone just switches to musl + busybox.

Or doas. Much simpler.

Re: Heap-based buffer overflow in Sudo

#169

Post by roca »

ddevault wrote: post #109
vitno wrote: post #108

Earlier quoted context omitted.

Except that Rust is also a much much more expressive language. Even ignoring things like solid module support and libraries you'll find your Rust programs to be much fewer LoC (assuming bug/LoC is the right metric) for equivalent functionality. I agree that rewrites have the serious potential to introduce new bugs and the cost is rarely worth it if the codebase is actually that stable and low througput, but the reali…

Lines of code is a poor approximation for complexity. Rust programs are shorter, but they are not less complex. The AST is similar and the graph of relationships between different parts of the code is much more complex than in C. Overall I'd say it balances at best, if not that Rust is more complex.

The sudo code in question is typical C: string processing with pointers and hand-rolled byte manipulation, size calculations, manual buffer allocation and freeing, and so on. The Rust equivalents of all this are far simpler.

Re: Heap-based buffer overflow in Sudo

#170

Post by megous »

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…

su pulls in random set of currently configured PAM modules, due to requiring authentication.

Anyone checked what buggy horrors await in all those modules? And it's not a static set of old trusty modules either. The fresh new complicated stuff is being added, like systemd-homed, and so on.

pam_systemd and pam_systemd_home have by itself the size of all other 46 PAM modules combined (on my Arch system).

Post reply on HN