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

111–120 of 328 posts

Re: Heap-based buffer overflow in Sudo

#111

Post by vitno »

ddevault wrote: post #106
myrrlyn wrote: post #102

Earlier quoted context omitted.

helps that a 10kloc c program getting riir'd probably won't be a 10kloc rust program, because c doesn't have libraries and rust does. it is literally impossible to write "a small codebase focused on its key value-adds without distractions" in a language that doesn't have strings and requires you to build a dictionary from scratch

>helps that a 10kloc c program getting riir'd probably won't be a 10kloc rust program, because c doesn't have libraries and rust does. What? Rust has so few libraries of significance that it still depends on C for security-critical areas like SSL. >it is literally impossible to write "a small codebase focused on its key value-adds without distractions" in a language that doesn't have strings and requires you to build…

that's not true these days, rustls is a great TLS lib that has been through at least one serious external security audit.

https://cure53.de/pentest-report_rustls.pdf

Re: Heap-based buffer overflow in Sudo

#112

Post by tgbugs »

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 certain point of view if you have someone in the habit of repeatedly typing sudo over and over again then all sudo has really done is open up every single terminal to be a gateway to the nether realm of super user privs. And in this case, more attack surface.

Re: Heap-based buffer overflow in Sudo

#113

Post by saagarjha »

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.

Address Sanitizer is not perfect, nor is it suitable to ship in production.

Re: Heap-based buffer overflow in Sudo

#114

Post by saagarjha »

ddevault wrote: post #106
myrrlyn wrote: post #102

Earlier quoted context omitted.

helps that a 10kloc c program getting riir'd probably won't be a 10kloc rust program, because c doesn't have libraries and rust does. it is literally impossible to write "a small codebase focused on its key value-adds without distractions" in a language that doesn't have strings and requires you to build a dictionary from scratch

>helps that a 10kloc c program getting riir'd probably won't be a 10kloc rust program, because c doesn't have libraries and rust does. What? Rust has so few libraries of significance that it still depends on C for security-critical areas like SSL. >it is literally impossible to write "a small codebase focused on its key value-adds without distractions" in a language that doesn't have strings and requires you to build…

Having written dictionary implementations in C, I would be very interested in seeing your implementation that fits in two dozen lines of code.

Re: Heap-based buffer overflow in Sudo

#115

Post by [deleted] »

vitno wrote: post #111
ddevault wrote: post #106

Earlier quoted context omitted.

>helps that a 10kloc c program getting riir'd probably won't be a 10kloc rust program, because c doesn't have libraries and rust does. What? Rust has so few libraries of significance that it still depends on C for security-critical areas like SSL. >it is literally impossible to write "a small codebase focused on its key value-adds without distractions" in a language that doesn't have strings and requires you to build…

that's not true these days, rustls is a great TLS lib that has been through at least one serious external security audit. https://cure53.de/pentest-report_rustls.pdf

[deleted]

Re: Heap-based buffer overflow in Sudo

#116

Post by mulmen »

ddevault wrote: post #66
mulmen wrote: post #51

Earlier quoted context omitted.

Fair point re: complexity but how are CVEs in one codebase evidence of absence of bugs in another? Or said another way, is the lack of CVEs for doas an indication it is more secure or just less (ab?)used?

More CVEs can also sometimes be a function of exposure; Joe Random's program probably has no CVEs but that doesn't mean it's more secure than Jane Popular's tool. In this case, however, both sudo and doas have sufficient exposure to estimate their relative security using CVEs. We can also use the CVEs to characterize the kinds of vulnerabilities each has internally, without comparing them to each other. In general, t…

Sure, that makes sense. Would you also consider the re-occurrence of the same class of CVE? Like the environment variable parsing you mentioned before. If there were another CVE on that for doas would you consider it more damning than the first?

Re: Heap-based buffer overflow in Sudo

#117

Post by ddevault »

mulmen wrote: post #116
ddevault wrote: post #66

Earlier quoted context omitted.

More CVEs can also sometimes be a function of exposure; Joe Random's program probably has no CVEs but that doesn't mean it's more secure than Jane Popular's tool. In this case, however, both sudo and doas have sufficient exposure to estimate their relative security using CVEs. We can also use the CVEs to characterize the kinds of vulnerabilities each has internally, without comparing them to each other. In general, t…

Sure, that makes sense. Would you also consider the re-occurrence of the same class of CVE? Like the environment variable parsing you mentioned before. If there were another CVE on that for doas would you consider it more damning than the first?

Yeah, I would.

Re: Heap-based buffer overflow in Sudo

#118

Post by gpm »

ddevault wrote: post #100
comex wrote: post #96

Earlier quoted context omitted.

> I would agree that that's more arguably a bug in libc than in doas, but also note that the startup code for any language has to consider this case. This is true, but for a language where dynamically sized arrays are a standard data type, the most natural thing to do is to start by collecting the arguments into an array (maybe copying the strings at this point, maybe not). All further argument parsing is done with t…

Aye, I agree. But if we consider that case, a similar mistake could be made: hard-coding argv[0]. The result is different, in that the program just aborts, but it's still the Wrong Thing To Do, and in both cases it never leads to anything exploitable. Bugs are bugs, no matter what language. We could come up with examples all day. Just head to your nearest Rust program's bug tracker :)

Aborting when argv[0] doesn't exist... is a perfectly reasonable thing to do? Someone called the program with arguments severely out of spec, crashing is fine.

Re: Heap-based buffer overflow in Sudo

#120

Post by gautamcgoel »

ddevault wrote: post #42
MayeulC wrote: post #40

Memory safety strikes again, it seems (overflow in a C string due to complex parameter parsing rules).

No, complexity strikes again. I haven't used sudo in years, preferring to use doas now. Its essential code is less than 500 lines and it does everything I've ever used sudo for, and that includes much more than `sudo `. $ man doas | wc -l 58 $ man doas.conf | wc -l 101 $ man sudo | wc -l 741 $ man sudoers | wc -l 3254 And a bonus: $ man sudoers | grep -C1 despair The sudoers file grammar will be described below in Ex…

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?

Post reply on HN