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

131–140 of 328 posts

Re: Heap-based buffer overflow in Sudo

#131

Post by LargoLasskhyfv »

wahern wrote: post #52
turminal wrote: post #48

Earlier quoted context omitted.

Briefly going through their website (sudo.ws) I am seriously wondering why anyone would want to put some of those features in a privilege management tool.

Todd Miller is a sharp developer and core OpenBSD contributor. I can only imagine the deluge of requests and pressure he faces to expand sudo. There's no end to the crazy stuff corporations demand, especially when it comes to integration--audit, logging, ldap, etc.

> There's no end to the crazy stuff corporations demand, especially when it comes to integration--audit, logging, ldap, etc.

Why should that be of concern to casual home use? Why do parts of a factory have to trickle down into my home? Wouldn't that be like the need to have a cow to drink milk, or a farm to have something to eat instead of a more apt product to buy for a reasonable price and in good quality?

Re: Heap-based buffer overflow in Sudo

#132

Post by roblabla »

musicale wrote: post #95
comex wrote: post #45

Earlier quoted context omitted.

But if sudo were written in Rust, it could have the same level of complexity and not be vulnerable. Yes, it would still be vulnerable to logic errors, like the last famous sudo bug where you pass -1 as the UID. But it wouldn't be vulnerable to this. (And this isn't the first memory safety bug to be found in sudo.) Yes, sudo's complexity is useless for 99.99% of its users. But wouldn't it be nice if the result were me…

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

Compile it for wasm and use a wasm runtime built in a memory-safe language? I believe some wasm runtimes allow for making raw syscalls.

Re: Heap-based buffer overflow in Sudo

#133

Post by Arnavion »

TheDong wrote: post #23
2bitencryption wrote: post #9

I'm curious, is this one implementation of sudo really used everywhere? I was under the impression that different Linux userspaces sometimes implement these common commands differently. Like "ls" sometimes actually being aliased to a bash script, or maybe BSD having one implementation and Ubuntu another. Is that not the case? Is "sudo" not maintained by an entity like gnu, bsd, etc? edit - in other words, I always as…

> Like "ls" sometimes actually being aliased to a bash script, or maybe BSD having one implementation and Ubuntu another It is true that BSD and linux sometimes have different implementations of posix commands. The vast majority of linux distros are using the same gnu coreutils though. There are alternate implementations (like busybox, among others), but they're not often used in desktop distros. I'm curious if you h…

They probably didn't mean replace wholesale, but that `ls` in a shell is a wrapper around the underlying coreutils `ls` with some extra flags by default. Eg:

    $ (. /etc/os-release; echo "$NAME:$VERSION_ID")

    openSUSE Tumbleweed:20210121

    $ command -v ls

    alias ls='_ls'

    $ grep -A6 -B1 '_ls ()' /etc/profile.d/ls.bash

    bash|dash|ash)
        _ls ()
        {
            local IFS=' '
            command ls $LS_OPTIONS ${1+"$@"}
        }
        alias ls=_ls
        ;;

Re: Heap-based buffer overflow in Sudo

#134

Post by roblabla »

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

For what it's worth, rustls relies on ring which has primitives written in C and ASM because getting constant-time operation guarantees from Rust is Very Hard. Though progress is being made on this area.

Re: Heap-based buffer overflow in Sudo

#135

Post by TomSwirly »

tbrownaw wrote: post #121
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…

> 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 PR does not include tests" is not the same as "nobody performed any tests" is not the same as "nobody actually noticed a bug". And of course, it's perfectly reasona…

"You can't prove no one tested that!" is not really a good basis for robust software design.

Re: Heap-based buffer overflow in Sudo

#136

Post by statquontrarian »

statquontrarian wrote: post #124

How does this story not have a billion upvotes? HN should introduce sticky posts just for this bug and keep it at the top of the homepage for weeks. > exploitable by any local user [...] without authentication > introduced in July 2011 [...] in their default configuration > full root privileges

The actual commit: https://github.com/sudo-project/sudo/commit/8255ed69

Re: Heap-based buffer overflow in Sudo

#137

Post by kaba0 »

gautamcgoel wrote: post #120
ddevault wrote: post #42

Earlier quoted context omitted.

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?

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.

Re: Heap-based buffer overflow in Sudo

#139

Post by zamadatix »

ddevault wrote: post #86
vitno wrote: post #75

Earlier quoted context omitted.

I agree Rust is not a panacea and that rewrites create their own set of problems, the only issue with this analysis is assuming 1/10 bugs are memory corruption related. Both Chrome & Microsoft found about 70% of bugs to be memory safety related. I've heard similar numbers out of FB as well. The math looks a little different with that data. https://www.chromium.org/Home/chromium-security/memory-safet... https://www.zd…

Even if we run the same math with 7 out of 10 bugs being memory safety related, and assuming that Rust prevents all of them, those same example programs end up with 30 bugs in Rust and 10 bugs in C. There's another argument I could make, too. Look at the bug tracker for the program you want to rewrite in Rust, examining the historical bugs. You'll find that there are often hundreds or thousands of mistakes that they…

So again why does it have to be "rewrite at 1/10th the complexity in " (10%) vs "rewrite in at full complexity" (30%)? What's preventing using Language B for the complexity rewrite and getting 0.1 * (1 - 0.7) = 3%?

Rewrites do bring the chance to Royally Screw it Up™ so it's certainly not simply a product of "it is now written in therefore safe" but as it said not only have projects shown the security didn't fall apart but they have shown the opposite.

I agree you don't get there by a bunch of yolo rewrites to whatever is hip though, it has to be a planned effort that isn't rushed. Much in the same way quickly writing a small replacement utility does not inherently make it more secure or reliable than an existing significantly more complex utility. Even just trying to shave some functionality off the existing code is rife with "but how does removing this piece affect the app remaining logic" and takes time and effort to do right.

Both methods do have to be done right and both do greatly help security but there is nothing about picking a memory safe language or making a significantly narrower focused utility that preclude each other.

Re: Heap-based buffer overflow in Sudo

#140

Post by saagarjha »

ddevault wrote: post #122
saagarjha wrote: post #114

Earlier quoted context omitted.

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

Threw together an example (untested, with obvious errors) to give you an idea of what it could look like: https://paste.sr.ht/~sircmpwn/3122d4a27a8e5312462e2329bf7ed6... Actually managed to get it to exactly 2 dozen lines of code, not including the header, which isn't bad for an off-the-cuff remark. You'd naturally expand or shrink this with whatever subset of map functions you require, like key/value enumeration, ob…

Ok, that makes more sense. I was considering a slightly more fully-featured table and including the header (see: https://gist.github.com/saagarjha/00faa1963023206a8ccd987798...) and I was a couple times larger than your number, so I was trying to figure out what you were doing that I was unable to replicate…
Post reply on HN