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

141–150 of 328 posts

Re: Heap-based buffer overflow in Sudo

#141

Post by swsieber »

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.

Lines of code is great approximation for complexity, or at least how many bugs you're writing: https://softwareengineering.stackexchange.com/questions/1856...

Re: Heap-based buffer overflow in Sudo

#142

Post by gpm »

ddevault wrote: post #128
gpm wrote: post #118

Earlier quoted context omitted.

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?

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.

Re: Heap-based buffer overflow in Sudo

#143

Post by saagarjha »

tbrownaw wrote: post #121
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 reasona…

Tests you perform locally should probably be described, if not encoded into something that other people can run as well.

Re: Heap-based buffer overflow in Sudo

#144

Post by ddevault »

swsieber wrote: post #141
ddevault wrote: post #109

Earlier quoted context omitted.

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.

Lines of code is great approximation for complexity, or at least how many bugs you're writing: https://softwareengineering.stackexchange.com/questions/1856...

Perhaps indeed! But a crucial distinction is that I consider the complexity in the langauge, compiler, and standard library to all be influences on your program's total complexity as well. Using std::List (or whatever you call it) has the same total complexity as writing your own little growable array.

Re: Heap-based buffer overflow in Sudo

#145

Post by deckard1 »

kuschku wrote: post #105
axaxs wrote: post #92

Earlier quoted context omitted.

Poettering to save the day with systemd-sudo?

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

> integrates with your DE instead of expecting passwords on the terminal.

There's nothing inherently insecure about passwords on the terminal, and certainly nothing a DE can do better. I have yet to see a display manager or lock screen app that knows what the hell PAM is doing. Try doing even the simplest things with PAM, such as getting a fingerprint reader or Yubikey working, and every single display manager simply chokes.

I'm not sure which is more of a Byzantine mess: Linux authentication and authorization, or Linux audio.

Re: Heap-based buffer overflow in Sudo

#146

Post by kaba0 »

roblabla wrote: post #132
musicale wrote: post #95

Earlier quoted context omitted.

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

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.

Re: Heap-based buffer overflow in Sudo

#147

Post by ddevault »

zamadatix wrote: post #139
ddevault wrote: post #86

Earlier quoted context omitted.

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…

So again why does it have to be "rewrite at 1/10th the complexity in " (10%) vs "rewrite in at full complexity" (30%)? What's preventing using Language B for the complexity rewrite and getting 0.1 * (1 - 0.7) = 3%? Rewrites do bring the chance to Royally Screw it Up™ so it's certainly not simply a product of "it is now written in therefore safe" but as it said not only have projects shown the security didn't fall apa…

You can do both! But because simplicity has a substantially greater impact than the language choice, I think it's better to focus on that. Right now, the ecosystem is focusing more on the language choice, and hardly talking about simplicity at all. And particularly in the case of Rust, I think it fails simplicity a lot in its own ways - in the stdlib, the compiler and toolchain, the language design - and the trade-offs don't really make sense for a lot of use cases that people are pining for it over anyway.

Re: Heap-based buffer overflow in Sudo

#148

Post by saagarjha »

fattire wrote: post #8

sudo built with ASLR doesn't make a difference? NM: - we can defeat ASLR by partially overwriting the function pointer getenv_fn (which points to the function sudoers_hook_getenv() in the shared library sudoers.so); and luckily, the beginning of sudoers.so contains a call to execve() (or execv()):

This is not sudo being build with ASLR, but library ASLR.

Re: Heap-based buffer overflow in Sudo

#149

Post by ddevault »

gpm wrote: post #142
ddevault wrote: post #128

Earlier quoted context omitted.

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

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.

Re: Heap-based buffer overflow in Sudo

#150

Post by zests »

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.

sudo su

My favorite command.

Post reply on HN