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

231–240 of 328 posts

Re: Heap-based buffer overflow in Sudo

#231

Post by pocketgrok »

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.

Maybe something that’s sole purpose is privilege escalation, like sudo, should come with some expectation of responsibility.

Re: Heap-based buffer overflow in Sudo

#232

Post by roca »

scaramanga wrote: post #216
roca wrote: post #165

Earlier quoted context omitted.

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

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?

Re: Heap-based buffer overflow in Sudo

#233

Post by pocketgrok »

pfundstein wrote: post #217
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…

Did you just call C a high level language?

Technically, it is. But usage of the term has shifted a lot over the last 50 years.

Re: Heap-based buffer overflow in Sudo

#234

Post by samatman »

brigandish wrote: post #172
arp242 wrote: post #157

Earlier quoted context omitted.

There are tests. Are there enough tests? Maybe not. But people can do in their spare time whatever they want, including writing code without tests.

People can do what they want in their spare time, true, but that it is their spare time does not make the action responsible or irresponsible, nor does it shelter them from responsibility. Not wearing a seatbelt when at work or in your spare time is irresponsible . Writing code, without tests, that others use (and for security at that) is irresponsible .

Y'know, I don't agree with you in general, and you did put this in general terms.

But this is frakkin sudo we're talking about.

It's a wonder that anything works, ever.

Re: Heap-based buffer overflow in Sudo

#235

Post by jart »

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

OpenBSD is a fabulous project. I've been working on tool called Cosmopolitan which helps Mac/Linux/Windows/FreeBSD developers write software that's compatible with OpenBSD: https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s... As you can see, I've studied these systems a lot and I've got to say that OpenBSD is the closest to the Bell Labs roots I've seen from community distros. It takes a certain degree of judiciousness to maintain that authenticity and the clairvoyance w.r.t sudo should be all the proof we need that OpenBSD is up to something good.

Re: Heap-based buffer overflow in Sudo

#236

Post by pjmlp »

nsajko wrote: post #59
pjmlp wrote: post #12

Earlier quoted context omitted.

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…

First, C has been known to never have been a good option for systems programming, and has UNIX adoption to thank for its existence, instead of having faded into the history of systems programming languages.

Quote from C.A.R Hoare at his Turing Award speech in 1981:

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

This is what is missing to force C to finally stop being the JavaScript/PHP of systems programming, liability for exploits with hefty sums.

Second, I keep being told that it is possible to write perfectly safe code in C, it is just a matter of using the tools.

From your assertion, it appears the sudo project has some learning to put into place then, because code reviews weren't enough to prevent this exploit.

Re: Heap-based buffer overflow in Sudo

#237

Post by pjmlp »

pfundstein wrote: post #217
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…

Did you just call C a high level language?

Indeed,

"C Is Not a Low-level Language, Your computer is not a fast PDP-11."

https://queue.acm.org/detail.cfm?id=3212479

Re: Heap-based buffer overflow in Sudo

#238

Post by pjmlp »

scatters wrote: post #104
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…

It's called AddressSanitizer. You enable it with the compiler flag -fsanitize=address. It's supported by clang, gcc and lately MSVC.

And used by around 36% of developers that bother to answer surveys.

Re: Heap-based buffer overflow in Sudo

#239

Post by riffraff »

arp242 wrote: post #129
rincebrain wrote: post #79

Earlier quoted context omitted.

It's not GNU's `sudo`, it's under an ISC-style license, and is maintained by an OpenBSD developer, so it's closer to "BSD's sudo" (though OpenBSD has been shipping `doas` instead for a little while now).

sudo even predates GNU by several years.

wow, I never realized sudo is from 1980[0]! I thought it was a product of the late '90s. It's actually incredible it has managed to stay around this long.

[0] https://www.sudo.ws/history.html

Re: Heap-based buffer overflow in Sudo

#240

Post by pwdisswordfish6 »

jart wrote: post #219
lmm wrote: post #198

Earlier quoted context omitted.

> Fair enough but what do you recommend? MirageOS unikernels like were mentioned yesterday? Get away from running network services on Linux entirely?

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.
Post reply on HN