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

171–180 of 328 posts

Re: Heap-based buffer overflow in Sudo

#171

Post by roca »

ddevault wrote: post #144
swsieber wrote: post #141

Earlier quoted context omitted.

Lines of code is great approximation for complexity, or at least how many bugs you're writing: https://softwareengineering.stackexchange.com/questions/1856...

Perhaps indeed! But a crucial distinction is that I consider the complexity in the langauge, compiler, and standard library to all be influences on your program's total complexity as well. Using std::List (or whatever you call it) has the same total complexity as writing your own little growable array.

From the point of view of bugginess, complexity in the implementations of massively popular libraries is far less of an issue than code you just wrote yourself, because the code in those libraries will have received much more testing than the code you just wrote yourself. So it doesn't really make sense to just add the complexity of components up like that.

Re: Heap-based buffer overflow in Sudo

#172

Post by brigandish »

arp242 wrote: post #157
jolux wrote: post #156

Earlier quoted context omitted.

No, but having tests is an acceptable baseline.

There are tests. Are there enough tests? Maybe not. But people can do in their spare time whatever they want, including writing code without tests.

People can do what they want in their spare time, true, but that it is their spare time does not make the action responsible or irresponsible, nor does it shelter them from responsibility.

Not wearing a seatbelt when at work or in your spare time is irresponsible.

Writing code, without tests, that others use (and for security at that) is irresponsible.

Re: Heap-based buffer overflow in Sudo

#173

Post by j16sdiz »

gameswithgo wrote: post #160
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…

Rust would have prevented the -1 as a UUID too, because you would have used a sum type (Rust enums) instead of a sigil there. Its easier, its idiomatic, its more clear, and the compiler knows how to optimize the overhead away a lot of the time.

It is a uid (as in user id), not uuid. Don’t think you can use sum type for that

Re: Heap-based buffer overflow in Sudo

#174

Post by steveklabnik »

j16sdiz wrote: post #173
gameswithgo wrote: post #160

Earlier quoted context omitted.

Rust would have prevented the -1 as a UUID too, because you would have used a sum type (Rust enums) instead of a sigil there. Its easier, its idiomatic, its more clear, and the compiler knows how to optimize the overhead away a lot of the time.

It is a uid (as in user id), not uuid. Don’t think you can use sum type for that

It is a user id, but that bug happened because a -1 was being returned as an error code in one place, and then being accidentally passed in another place. The sum type would be used as the “this possibly errors” return type in the first function, making the bug effectively impossible to happen by accident.

Re: Heap-based buffer overflow in Sudo

#175

Post by jolux »

arp242 wrote: post #157
jolux wrote: post #156

Earlier quoted context omitted.

No, but having tests is an acceptable baseline.

There are tests. Are there enough tests? Maybe not. But people can do in their spare time whatever they want, including writing code without tests.

The thing is, "do what thou wilt" is clearly indefensible as an engineering standard, and I doubt you would disagree. So yes, I can't force anyone to write tests.

However, I do want to see programming as a culture adopt a higher standard when it comes to checking their work, and I think the continued prevalence of bugs like this are an indicator that we actually need to do so. I'm not asking for NSA-proof because that's not reasonable. But memory safety is a solved problem, and we need to be putting in the legwork to make more of our stack memory safe.

Re: Heap-based buffer overflow in Sudo

#176

Post by gerdesj »

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…

"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 risk assessment and attempt to mitigate as best you can. I read a lot of blogs and have a fair amount of logging and analytics lying around the place (and that's just at home).

Fairly recently I found that my wife's car had loose nuts on the front nearside wheel. That was a change to fix a worn tyre for obvious safety reasons but for whatever reason the fixings were not done up properly. I think they were done up finger tight but a distraction caused the mechanic to forget to use a spanner (wrench) to finish the job to spec. The wheel seemed to work fine but you would get a low rumble sound on corners. It was not a trivial to diagnose fault because you had to notice it before failure - I'm a (non chartered) Civ Eng and IT bod but not a mechanic. There is a minimally screwed on plastic cover that stopped the bolts from flying out - not much.

A car wheel is a thing we can all look at and see that the four bolts are not working properly, once you remove the plastic cover and see them wobble.

Now that is what you can do to protect yourself (risk assess, mitigate etc.) However there should also be something that protects "civilians" and I think that is what is missing. I'm not too sure how we do that.

Re: Heap-based buffer overflow in Sudo

#177

Post by jonhohle »

TomSwirly wrote: post #135
tbrownaw wrote: post #121

Earlier quoted context omitted.

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

In addition to the value of repeatability, it’s just being a good human to show and share your work.

Re: Heap-based buffer overflow in Sudo

#178

Post by turminal »

LargoLasskhyfv wrote: post #131
wahern wrote: post #52

Earlier quoted context omitted.

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?

The bigger a piece of software is, the more opportunities there are for bugs. And the correlation isn't linear.

For home users there is doas, also written by a OpenBSD developer. It's really simple, but I never found anything to be missing for my use case. All the logging and auditing and whatnot can (and imo should) be performed somewhere else.

Re: Heap-based buffer overflow in Sudo

#179

Post by turminal »

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

I can't possibly see how PAM was ever considered a good idea.

Re: Heap-based buffer overflow in Sudo

#180

Post by arp242 »

brigandish wrote: post #172
arp242 wrote: post #157

Earlier quoted context omitted.

There are tests. Are there enough tests? Maybe not. But people can do in their spare time whatever they want, including writing code without tests.

People can do what they want in their spare time, true, but that it is their spare time does not make the action responsible or irresponsible, nor does it shelter them from responsibility. Not wearing a seatbelt when at work or in your spare time is irresponsible . Writing code, without tests, that others use (and for security at that) is irresponsible .

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

Post reply on HN