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

221–230 of 328 posts

Re: Heap-based buffer overflow in Sudo

#221

Post by zaarn »

tgbugs wrote: post #192
tbrownaw wrote: post #125

Earlier quoted context omitted.

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

I firmly agree that sharing passwords is bad, however I can't imagine a threat model where password sharing among multiple parties is more risky than giving multiple people sudo. As zests points out, practically there is no difference because anyone with sudo can change the root password, they are already root, so the auditing use cases is moot if the logging system can't distinguish between two users sudo sued into…

sudo can be restricted to specific commands, so you can restrict non-root users to do VERY specific actions (ie, the webdev can reload apache2 but not restart or stop it or take any other action).

This means the webdev has the least amount of access necessary for their work without giving them straight up root or using setuid on a script, which can lead to easy bugs (did you check PATH?)

Re: Heap-based buffer overflow in Sudo

#222

Post by jart »

mtrycz2 wrote: post #76
jeffbee wrote: post #67

Earlier quoted context omitted.

The GNU project is wall-to-wall toxic waste, but I note for the record that I don't think sudo is a GNU program and IIRC it's not even GPL.

Three decades of free software that generated billions upon billions of revenue and a big part of existing infrastructure is built upon is far from "wall to wall toxic waste". I'm not a fanboy for the sake of it, but you're being a little over your head here.

Online Linux services are so powerful, that they can even ban the president of the united states of america.

Re: Heap-based buffer overflow in Sudo

#223

Post by kevingadd »

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.

Asan binaries should never be shipped in security sensitive environments. It's not designed for that. It's unsafe.

Re: Heap-based buffer overflow in Sudo

#224

Post by arp242 »

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.

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.

Re: Heap-based buffer overflow in Sudo

#225

Post by jart »

stevekemp wrote: post #208
jart wrote: post #31

Developers: your moment has come at last to humble your local system administrator for wearing those "I read your emails" t-shirts. This is as day zero as day zero gets. Red Hat and Debian published their security announcements just two hours ago at the exact same moment this was posted on Hacker News. It would have been more responsible to keep something this bad under wraps a bit longer. Because all the people who…

cpanel is a web-based thing though, isn't it? You'd need shell access to the host to execute `sudo` and attempt to exploit it.

CPanel is a web gui for managing Linux systems. It's mainly used to configure and resell apache virtual hosts. Shell accounts is one of the things it manages. These companies normally have like hundreds of customers per server since they charge ~$1/month for hosting. So anyone who pays one dollar a month extra for shell access can compromise a whole lot of people. I tried tweeting at these virtual hosting providers to bring the vulnerability to their attention, but no one's responded.

Re: Heap-based buffer overflow in Sudo

#226

Post by masklinn »

jart wrote: post #220
acdha wrote: post #189

Earlier quoted context omitted.

We’d all like that, true, but look here: https://github.com/sudo-project/sudo/graphs/contributors That’s one maintainer, not even full time according to his résumé. What you just described is multiple specialists and some supporting tools, so another way of looking at this is to ask how much value the IT world has gotten from sudo but not contributed back in support. When something is this widely used, it’s easy to f…

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

Re: Heap-based buffer overflow in Sudo

#227

Post by jart »

megous wrote: post #170
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).

Is there any part of the Linux system that systemd hasn't penetrated yet? It controls boot, processes, authentication, time, dns, proxies, etc. The GNOME Foundation unilaterally required all distros adopt Systemd ten years ago without any community support. Yocto makes it exceedingly hard to create embedded devices that don't have Systemd, so it's probably lurking on all your IoT devices.

Re: Heap-based buffer overflow in Sudo

#229

Post by higerordermap »

At this point, can somebody recommend linux security best practices on desktop? I already have two user accounts one for important stuff and other for unimportant stuff. I prefer to use sandboxed apps, but flatpaks don't look well maintained compared to official repositories, and often unofficial. Firejail seems quite controversial due to use of UserNS? What do veterans in security recommend for sandboxing of user apps?

Re: Heap-based buffer overflow in Sudo

#230

Post by roca »

kortex wrote: post #206
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,…

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

Post reply on HN