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

251–260 of 328 posts

Re: Heap-based buffer overflow in Sudo

#251

Post by lmm »

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

Much of the point of suggesting Mirage was to get away from C - my position is that the correctness costs of C's undefined behaviour (as implemented by real-world C compilers), limited testing support, poor dependency management and so on are too high.

Re: Heap-based buffer overflow in Sudo

#252

Post by eklitzke »

megous wrote: post #162
deckard1 wrote: post #145

Earlier quoted context omitted.

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…

How else would you implement PAM? The whole point is that you can write arbitrary code to implement whatever custom authentication policy you have, so it needs to be able to dlopen things. And if you don't like the PAM policy written by your distro, you're free to change it by implementing your own authentication policies, or dropping things you don't care about (like systemd, you can configure PAM to just use /etc/passwd and /etc/shadow if you like).

sshd needs to run as root (obviously) because it grants login shells to people, so it needs to run in a privileged context. And the PAM modules it executes also need to be run as root, because PAM modules need to do things like read /etc/shadow.

Re: Heap-based buffer overflow in Sudo

#253

Post by lmm »

danaris wrote: post #205
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?

Does it have full support for all the kinds of stacks people are running on Linux today? Is there a robust ecosystem of MirageOS users online able to help troubleshoot issues from the simple to the arcane? Is it supported by VPS providers the world over? Personally, while I doubt these are the case, having never heard of MirageOS before, I'm willing to be proven wrong. However, if the answer to any of these is "no",…

> Does it have full support for all the kinds of stacks people are running on Linux today?

No, of course not; the only thing that supports everything that Linux supports is Linux. But most use cases don't use every part of Linux.

> Is there a robust ecosystem of MirageOS users online able to help troubleshoot issues from the simple to the arcane?

I doubt it, but how do we get to there from here except by more users starting to use it?

> Is it supported by VPS providers the world over?

Yes, since what you build is just a VM image.

> However, if the answer to any of these is "no", I have a hard time seeing how "just abandon Linux wholesale for NewShinyThing" is a viable option for more than a tiny subset of users. (Even if they're all "yes", it's still a wildly unrealistic expectation...)

I don't disagree as such, but I do think that at this point building anything on these insecure foundations is throwing good money after bad / building castles on sand. Probably 95% of the time you build something that serves your present business purposes, accept a certain amount of insecurity, and get on with your life. But it's worth putting a bit of effort into looking for better ways to do things.

Re: Heap-based buffer overflow in Sudo

#254

Post by kaba0 »

cheph wrote: post #247
iovrthoughtthis wrote: post #242

Earlier quoted context omitted.

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

For some code, yes. What about a complete refactor of the core functionality of said program, with parallelism and the like?

Re: Heap-based buffer overflow in Sudo

#255

Post by lmm »

arp242 wrote: post #224
lmm wrote: post #199

Earlier quoted context omitted.

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.

So people should be obliged to spend more of their free time? I know this is not exactly what you're trying to say, but it is what it comes down to.

Hmm. Maybe we shouldn't let unlicensed hobbyists expose their software to the internet - plenty of other things are too dangerous for unlicensed hobbyists to do. Though frankly the standard of commercial code is no better at the moment.

Re: Heap-based buffer overflow in Sudo

#256

Post by SSLy »

kaba0 wrote: post #137
gautamcgoel wrote: post #120

Earlier quoted context omitted.

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?

Modernizes C language = Zig. But I don’t see a point in using systems languages for the usual UNIX tools, they could be rewritten in a more secure language. In the rare case performance is important, there is FFI, but they are usually IO-bound so there is not much point.

I agree about secure languages. Last week I was daydreaming about reimplementing all non-RT parts in Lua.

Re: Heap-based buffer overflow in Sudo

#257

Post by cheph »

kaba0 wrote: post #254
cheph wrote: post #247

Earlier quoted context omitted.

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.

For some code, yes. What about a complete refactor of the core functionality of said program, with parallelism and the like?

I misread the comment I think, but either way, I am not arguing against automated tests, I was just trying to point out that for some fragments of a code base you should absolutely be able to tell correctness by looking at it.

Re: Heap-based buffer overflow in Sudo

#258

Post by [deleted] »

roca wrote: post #230
kortex wrote: post #206

Earlier quoted context omitted.

> e.g. code that uses funky casts, code that makes assumptions about data layout Maybe it shouldn't be doing that? Isn't that the whole point of something like a -safe flag? Increase security as you go along. Yes it is going to take time. The best time to plant a tree is 20 years ago, next best is today.

Maybe it shouldn't be doing that, but "recompiling C code in safe mode" only makes sense if you don't have to change the code much or at all. If you have to make all kinds of changes to the code you might as well just translate it into a different language.

[deleted]

Re: Heap-based buffer overflow in Sudo

#259

Post by gerikson »

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 .

From https://www.sudo.ws/license.html

> THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

If you don't like this license, you're free to use other software.

Re: Heap-based buffer overflow in Sudo

#260

Post by gerikson »

breakingcups wrote: post #249
masklinn wrote: post #226

Earlier quoted context omitted.

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

You're supposed to disable javascript in your browser.
Post reply on HN