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

241–250 of 328 posts

Re: Heap-based buffer overflow in Sudo

#241

Post by scaramanga »

roca wrote: post #232
scaramanga wrote: post #216

Earlier quoted context omitted.

I think the practical issues you describe like rebuilds of packages and so on are very real if we're talking about general adoption. But if we're talking about recompiling a handful of SUID programs which make up a TCB then I think a proposition like that has a lot of merit and can't be easily dismissed. Any C code that needs changing to deal with fat-pointers is probably already UB in C (or at best, has some impleme…

If we're talking about recompiling a handful of SUID programs, why not just manually translate them into Rust or something similar?

Yes, that's probably a good idea.

But it comes with costs. Someone has to learn Rust and then convert all of these programs. And it also has the issue that Rust programs are only memory safe if the unsafe keyword is not used anywhere in the program (correct me if wrong?). So it looks like the effort to do such thing, while noble, and valiant, is essentially an experiment with an uncertain pay-off that could turn out to be small or large.

Much more interesting (to my mind, anyway) is something like Miri. The rust interpreter, which uses fat-pointers to make things (more? completely? someone more informed can correct me..) memory-safe by inserting some relatively lightweight run-time checks.

And, then again, if such a thing could be compiled rather than interpreted (some things similar to this already exist, like C with fat-pointers). And if the source language was C (or something like it) or C++ (or some future C++) then the human aspect of re-training a generation of programmers goes from being a very big hurdle, to a much lower one.

At that point the benefits go up quite a bit, and the costs come down quite a bit. And I think that might be a promising path to overcoming the sort of human/political hurdles/inertia involved in rewriting the world :)

Re: Heap-based buffer overflow in Sudo

#242

Post by iovrthoughtthis »

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…

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

Broadly yes, but it would be hubris to claim you can tell the correctness of all code from merely looking at it.

Re: Heap-based buffer overflow in Sudo

#243

Post by jart »

pwdisswordfish6 wrote: post #240
jart wrote: post #219

Earlier quoted context omitted.

Use Actually Portable Executable which enables you to compile textbook C programs as unikernels that boot on bare metal, as well as execute natively on all the existing operating systems too (without needing a runtime or interpreter). We've been working hard to democratize ring0 privileges since spectre has made the performance costs of having an operating system too high: https://github.com/jart/cosmopolitan/issues/…

The libc is a runtime.

By runtime I meant to say external runtimes. Your cosmo binaries are statically don't depend on anything except stable kernel interfaces, when you run on mac/nt/linux/bsd. That means it doesn't need to link any .so files like the glibc runtime. Therefore you won't be impacted by things like linux distro versioning and incompatibilities.

Re: Heap-based buffer overflow in Sudo

#244

Post by nahsjP »

mbrubeck wrote: post #203

Just ten days ago on Hacker News, we had a C programmer claiming that “buffer over-runs are a rare class of bugs, and a class of bugs that are (at least on the heap, and often on the stack) trivial to find and fix” [1]. As a bonus, the person who wrote that turned out to have published C code containing multiple exploitable buffer overflows. [1]: https://news.ycombinator.com/item?id=25806533

Of course not as secure as Firefox, which enables WASM by default. Or Chromium, which runs chrome-sandbox under suid.

Re: Heap-based buffer overflow in Sudo

#245

Post by magnostherobot »

lmm wrote: post #199
arp242 wrote: post #180

Earlier quoted context omitted.

> Writing code, without tests, that others use (and for security at that) is irresponsible. You can choose to run this code, or you can choose not to run this code. It's really up to you. This is very different from a sealbelt, as I can't choose to not have an accident with you, potentially causing a needless fatality.

This code is advertised as a security tool, is it not? The only reason anyone runs sudo is because it (supposedly) improves their security. I think some responsibility comes with that.

I don't use sudo to improve my security; I use sudo because it's what I've become familiar with.

I don't want to come across as pedantic - the point I mean to make is that I think a lot of people use sudo without thinking about it much. Sudo's just "the way to use linux" for a lot of people I know.

I don't think the sudo contributors should be labelled as irresponsible, because everything they've added to the project is available for the public to see and scrutinise. I don't think they've ever mislead people; rather that people have assumed things.

Maybe people who care about security will notice now that sudo doesn't have comprehensive testing, and will make their own alternative.

Re: Heap-based buffer overflow in Sudo

#246

Post by Someone »

arp242 wrote: post #152
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…

Maybe expecting projects that mostly consist of a single guy working on it in their spare time to be "NSA proof" isn't really realistic? Folk love to bring up "responsibility" and all of that, but you can't really expect people to bear the responsibility of the world on their shoulders for their spare time projects. It's neither realistic nor fair.

No, you can’t. I think the blame shouldn’t be on this author, but on those choosing to install it or, worse, choosing to ship it on their OS.

OpenBSD replaced sudo with doas (http://man.openbsd.org/doas) in 2016 (https://www.infoworld.com/article/3099038/openbsd-60-tighten...). It’s a safe bet it’s more secure than sudo.

Re: Heap-based buffer overflow in Sudo

#247

Post by cheph »

iovrthoughtthis wrote: post #242
tbrownaw wrote: post #121

Earlier quoted context omitted.

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

> And of course, it's perfectly reasonable to form beliefs about code from reading it. Broadly yes, but it would be hubris to claim you can tell the correctness of all code from merely looking at it.

For some code you should be able to do this, and if you can't then I don't think you should be writing code.

Coding is not brute forcing. I feel like this is taking an extreme position at the complete opposite end from not testing anything.

EDIT: Misread the comment I replied to. I agree that it is not likely that anyone can tell the correctness of all code from merely looking at it.

Re: Heap-based buffer overflow in Sudo

#248

Post by kazen44 »

masklinn wrote: post #226
jart wrote: post #220

Earlier quoted context omitted.

Wow he changed two million lines of the sudo codebase over the project history and made 10,548 commits. That's bonkers. Sudo is clearly doing a lot more under the hood than I thought it did. A simple security critical command shouldn't have that much churn. It should arc towards immutability like TeX, which has had like twelve changes in the last 40 years.

> Sudo is clearly doing a lot more under the hood than I thought it did. There’s a number of reasons openbsd dropped it, and all of them are fundamentally rooted in size and complexity: https://flak.tedunangst.com/post/doas

doas is a wonderful alternative to sudo.

For one, the config file is actually easy enough to read properly.

Re: Heap-based buffer overflow in Sudo

#249

Post by breakingcups »

masklinn wrote: post #226
jart wrote: post #220

Earlier quoted context omitted.

Wow he changed two million lines of the sudo codebase over the project history and made 10,548 commits. That's bonkers. Sudo is clearly doing a lot more under the hood than I thought it did. A simple security critical command shouldn't have that much churn. It should arc towards immutability like TeX, which has had like twelve changes in the last 40 years.

> Sudo is clearly doing a lot more under the hood than I thought it did. There’s a number of reasons openbsd dropped it, and all of them are fundamentally rooted in size and complexity: https://flak.tedunangst.com/post/doas

Sidebar: Wonderful post, but what an awful fake loading bar. Every time I switch from the tab / window to something else and switch back to continue reading I'm interrupted by it for no reason.

Re: Heap-based buffer overflow in Sudo

#250

Post by entelechy0 »

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…

Blaming the language is to blame yourself. You can't prevent mistakes that way.
Post reply on HN