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

321–328 of 328 posts

Re: Heap-based buffer overflow in Sudo

#321

Post by lfairy »

tinco wrote: post #163
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?

Rust is modernized C. You are looking for something that already exists. If C programmers would be looking for tools to help catch bugs like this and a better culture of testing and accountability they would be using Rust.

Yeah, Rust is about the simplest language that guarantees both memory safety + low-level control. Almost all of its complexity comes from having to satisfy both.

Re: Heap-based buffer overflow in Sudo

#322

Post by moistbar »

65a wrote: post #315
moistbar wrote: post #301

Earlier quoted context omitted.

sudo doesn't have to grant full root access to everyone in the group. It can be set up such that certain users only have the ability to run specified commands as root, which is handy for orgs where you might have a group of tier 1 techs that you want to be able to run certain scripts (written by tier 2 or 3, of course) that require root, but you don't trust the engineers enough to have root access to everything.

It is almost always the case that a sufficiently malicious user can find a way to turn that into full blown root access.

So that means they should get full blown root from the beginning?

Re: Heap-based buffer overflow in Sudo

#323

Post by bionade24 »

ddevault wrote: post #272
tinco wrote: post #163

Earlier quoted context omitted.

Rust is modernized C. You are looking for something that already exists. If C programmers would be looking for tools to help catch bugs like this and a better culture of testing and accountability they would be using Rust.

Rust is modernized C++.

I really don't understand why people donvoted this despite it's obvious. I don't align with you on anything else bc I don't hate C++ and Rust but I have to admit Rust and C++ suffer from the same problems.

Re: Heap-based buffer overflow in Sudo

#324

Post by vntok »

brigandish wrote: post #273
gerikson wrote: post #259

Earlier quoted context omitted.

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

What’s that got to do with what I wrote? Nothing, as far as I can see. If someone writes some crappy security software and hides behind a licence that only means those relying on it have joined them in being irresponsible. Responsibility multiplies, it’s not zero-sum.

Parent's comment has got everything to do with yours: you are feeling like the software somehow owes you to be merchandable and fit , while the software's license explicitely rejects ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS .

There is a large disconnect here.

Re: Heap-based buffer overflow in Sudo

#325

Post by vntok »

brigandish wrote: post #277
arp242 wrote: post #224

Earlier quoted context omitted.

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.

If they don’t like using their free time to write code they don’t have to, it’s free time not work. So, what it actually comes down to is that they didn’t bother to write tests. There was no time pressure, there was no urgency or requirement, they just couldn’t be bothered to do that prior to release. If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide. Have you seen something al…

> So, what it actually comes down to is that they didn’t bother to write tests. There was no time pressure, there was no urgency or requirement, they just couldn’t be bothered to do that prior to release.

Kindly go to the source repository.

> If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide. Have you seen something along those lines?

That's what a TODO file is for. There is one you can browse to here: https://www.sudo.ws/repos/sudo/file/tip/TODO

There is also literally a dozen lines in the LICENSE file saying that the software is not quite production ready (THE SOFTWARE IS PROVIDED "AS IS") and should not be relied upon (THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS).

It's all spelled black on white, not sure what you would want more from the author?

Re: Heap-based buffer overflow in Sudo

#326

Post by Spivak »

GoblinSlayer wrote: post #297
Sjonny wrote: post #294

Earlier quoted context omitted.

> Fair enough but what do you recommend? why do you need to have sudo? I'm perfectly fine without it. sudo is maybe useful in the case where others on the system don't need to know the a password to run as someone else (including root) but need to be able to do that anyway. sudo seems to have gotten a big installation bases through ubuntu and everybody thinks it's normal now, but really for me it's not.

I want to start and stop a couple of systemd services remotely. Currently I expose the command with sudo and run it under a remotely connected user. What are other options?

You don't actually have to be root at all to manage systemd services. If you give the user `org.freedesktop.systemd1.manage-units` in Polkit then they can just run systemctl as their user and it will work.

If you only want to allow specific units the authorizer is passed the unit under `action.lookup("unit")`.

Re: Heap-based buffer overflow in Sudo

#327

Post by Spivak »

moistbar wrote: post #322
65a wrote: post #315

Earlier quoted context omitted.

It is almost always the case that a sufficiently malicious user can find a way to turn that into full blown root access.

So that means they should get full blown root from the beginning?

IMHO yes because then you treat the access with the gravity that is required.

Re: Heap-based buffer overflow in Sudo

#328

Post by brigandish »

vntok wrote: post #325
brigandish wrote: post #277

Earlier quoted context omitted.

If they don’t like using their free time to write code they don’t have to, it’s free time not work. So, what it actually comes down to is that they didn’t bother to write tests. There was no time pressure, there was no urgency or requirement, they just couldn’t be bothered to do that prior to release. If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide. Have you seen something al…

> So, what it actually comes down to is that they didn’t bother to write tests. There was no time pressure, there was no urgency or requirement, they just couldn’t be bothered to do that prior to release. Kindly go to the source repository. > If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide. Have you seen something along those lines? That's what a TODO file is for. There is on…

From the comment I originally replied to:

> people can do in their spare time whatever they want, including writing code without tests

I did not refer to the Sudo project at all, so you might want to redirect your post to someone who did.

Post reply on HN