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

201–210 of 328 posts

Re: Heap-based buffer overflow in Sudo

#201

Post by sat_nam »

statquontrarian wrote: post #136
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

Thanks for sharing this. I was looking for it on the mercurial repo at sudo.ws, but the commit didn't match. I found it here: https://www.sudo.ws/repos/sudo/rev/f666191a4e80

Re: Heap-based buffer overflow in Sudo

#202

Post by 0xbadcafebee »

comex wrote: post #45
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…

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…

If sudo were written in Perl, it would also not be vulnerable.

Re: Heap-based buffer overflow in Sudo

#203

Post by mbrubeck »

Just ten days ago on Hacker News, we had a C programmer claiming that “buffer over-runs are a rare class of bugs, and a class of bugs that are (at least on the heap, and often on the stack) trivial to find and fix” [1].

As a bonus, the person who wrote that turned out to have published C code containing multiple exploitable buffer overflows.

[1]: https://news.ycombinator.com/item?id=25806533

Re: Heap-based buffer overflow in Sudo

#204

Post by 0xbadcafebee »

I was trying to find results for PAM in CVEDB so I could go "Everybody's freaking out about sudo but PAM ain't no saint neither (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=PAM)", but sudo's vulns seemed to really stack up last year: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo

Re: Heap-based buffer overflow in Sudo

#205

Post by danaris »

lmm wrote: post #198
gerdesj wrote: post #176

Earlier quoted context omitted.

"All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested" Fair enough but what do you recommend? Me, I try to keep people out of my systems that I don't trust. This particular snag needs local access but I will grant you that my web server or other exposed service might provide a local interface. Instead of throwing your hands up and screaming "crap" you do your…

> 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", 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...)

Re: Heap-based buffer overflow in Sudo

#206

Post by kortex »

roca wrote: post #165
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…

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.

Re: Heap-based buffer overflow in Sudo

#207

Post by zests »

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

How do you measure the sizes of these modules? I counted lines from source code and systemd pam code was a 1k-2k lines of C total and pam is 30k lines of C.

Re: Heap-based buffer overflow in Sudo

#208

Post by stevekemp »

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.

Re: Heap-based buffer overflow in Sudo

#209

Post by acdha »

anonymousiam wrote: post #200
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…

Does he moonlight for the NSA?

This response is the “must be aliens” of security. If you remotely think this is the case, ask whether one of the top intelligence agencies in the world would be more likely to attract attention to a deep cover operation many, many years in the making or would invest in making sure that the bug was well concealed so nobody else would be able to use it on, say, .gov servers. If you remember Dual EC_DRBG I know which one I’d bet on…

Re: Heap-based buffer overflow in Sudo

#210

Post by kortex »

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…

There are huge differences between running with user as sudo and running as root itself. Much more of an audit trail with sudo. You can trace which account ran which command. Sure you can cover your tracks with sudo but it's far harder than with bare root, even more so with shared accounts.
Post reply on HN