Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

openwall.com

Post reply on HN
Print view View original

31–40 of 82 posts

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#31

Post by adrianmonk »

bregma wrote: post #17
londons_explore wrote: post #4

Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?

Well, the compiler has no way of knowing if a function will later be a signal handler after linking, or even dynamic loading. There is no portable way to annotate all functions ever written or ever will be written as being async signal safe. Which functions are async signal safe varies with the operating system and runtime (eg. an unsafe function in linux-gnu might be safe in linux-musl or linux-bionic). Other than t…

> compiler has no way of knowing if a function will later be a signal handler after linking, or even dynamic loading

You could check it at runtime.

Just like with array bounds checking, in many cases the compiler could sometimes prove the runtime check isn't necessary and eliminate it.

> Which functions are async signal safe varies with the operating system and runtime

Annotations could enumerate specific platforms where it is safe or unsafe. Or you could annotate based on specific attributes of platforms that make it safe or unsafe.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#32

Post by gruturo »

qalmakka wrote: post #19
gruturo wrote: post #18

Earlier quoted context omitted.

Enterprises don't go for RHEL because it's free software, yay freedom! They go for it because it gives a very stable, solid foundation. They don't want a fragile base layer prone to breaking every day of the week. This involves backporting a lot of stuff (primarily security fixes) because you can't just upgrade any package to its latest version, it will have entirely new dependencies, potentially breaking changes etc…

I understand the business logic behind that. The point is, maybe they should consider paying the upstream developers to backport the stuff themselves instead of dabbling with C code they somewhat understand?

Tracing thousands of developers across the planet and drafting contracts in hundreds of jurisdictions, including some where you don't even have a branch office or any kind of legal presence? Ugh. And what if one's from an embargoed country? What if a primadonna asks for a million a day, or half of them don't deliver in time, go on holiday, win the lottery, fall in love, get into a dispute, refuse to work with you, don't have access to all the architectures for comprehensive testing, lose interest, change employer (and can't work with you anymore), or sell to some dodgy entity preparing the next sBoM attack.

....better to pay your own people. Hire them if they're available, sure, otherwise task an engineer with this.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#33

Post by Diederich »

qalmakka wrote: post #11

This is why I've always disliked Debian and Red Hat. 1. I hate the fact they have the hubris to think they can be smarter than the upstream developers and patch old versions 2. I hate the fact they don't ship vanilla packages, but instead insist on patching things for features that nobody relies on anyway, __because they're not upstream__. Maintainers should stick to downloading tarballs, building them and updating t…

Do you think there is a reason that some distros go through all of this additional trouble?

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#34

Post by fusslo »

JackSlateur wrote: post #28
gruturo wrote: post #18

Earlier quoted context omitted.

Enterprises don't go for RHEL because it's free software, yay freedom! They go for it because it gives a very stable, solid foundation. They don't want a fragile base layer prone to breaking every day of the week. This involves backporting a lot of stuff (primarily security fixes) because you can't just upgrade any package to its latest version, it will have entirely new dependencies, potentially breaking changes etc…

Compagnies I've worked for that uses redhat do so because they think paying will prevent them from working. As if, sudenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

> As if, suddenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

I love this

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#35

Post by tptacek »

stncls wrote: post #14

No vulnerability name, no website, concise description, neutral tone, precise list of affected distros (RHEL + derivatives and some EOL Fedoras) and even mention of unaffected distros (current Fedoras), plain admission that no attempt was made to exploit. What a breath of fresh air! (I am only joking of course. As a recovering academic, I understand that researchers need recognition, and I have no right to throw ston…

I don't think recognition for researchers is the big win for named vulnerabilities. In the places that matter, they can just describe their findings in a short sentence and get all the recognition that matters. The names are mostly for the benefit of users.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#37

Post by ericpauley »

tptacek wrote: post #35
stncls wrote: post #14

No vulnerability name, no website, concise description, neutral tone, precise list of affected distros (RHEL + derivatives and some EOL Fedoras) and even mention of unaffected distros (current Fedoras), plain admission that no attempt was made to exploit. What a breath of fresh air! (I am only joking of course. As a recovering academic, I understand that researchers need recognition, and I have no right to throw ston…

I don't think recognition for researchers is the big win for named vulnerabilities. In the places that matter, they can just describe their findings in a short sentence and get all the recognition that matters. The names are mostly for the benefit of users.

Security researchers definitely do the naming gimmick for personal brand purposes. This may not be as obvious when it’s successful, but academic papers routinely name vulnerabilities when there is no real benefit to users.

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#39

Post by loeg »

londons_explore wrote: post #4

Couldn't this entire class of bug be solved by annotating signal handlers in the source code and checking at compile time that anything called from a signal handler is async-signal-safe?

Static analysis tools would go a long way here, yes, and it should be a relatively straightforward analysis. You probably don't even need to explicitly annotate signal handlers, just examine arguments to calls to signal() and sigaction().

Re: CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child

#40

Post by rlpb »

qalmakka wrote: post #11

This is why I've always disliked Debian and Red Hat. 1. I hate the fact they have the hubris to think they can be smarter than the upstream developers and patch old versions 2. I hate the fact they don't ship vanilla packages, but instead insist on patching things for features that nobody relies on anyway, __because they're not upstream__. Maintainers should stick to downloading tarballs, building them and updating t…

Distributions patch to get consistent and integrated behaviour across the platform, including new features that require implementation into multiple places to be even minimally useful, and ports to newer APIs to make everything work against a single version of each library so that they do not conflict.

Upstreams generally don't do this until prompted, and sometimes resist until the path is proven and becomes best practice because distributions pushed it.

This process is mostly invisible to you because distributions have been successful at getting the changes needed for sane and consistent behaviour embedded into tools and expectations by default. All you see are the patches that are in flight or didn't make it.

If you want a distribution that does only minimal patching then there are distributions for that. The fact that the major distributions do patch speaks volumes about which approach results in a better experience for users.

Post reply on HN