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

11–20 of 82 posts

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

#11

Post by qalmakka »

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 them promptly when a new version is out. If there's no LTS available, pay upstream and get an LTS, don't take a random version and patch it forever just to keep the same version numbers, it's nonsensical and it was only a matter of time before people tried to exploit it. Just look at the XZ backdoor for instance, which relied on RedHat and Debian deploying a patched libsystemd.

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

#12

Post by stncls »

ta988 wrote: post #3

My understanding here is that it only impacts Redhat (and maybe derivatives)?

Yes, only RHEL 9 (the current version of RHEL) and its upstreams/downstreams (CentOS Stream 9, Rocky Linux 9, Alma Linux 9,...).

Also affected: Fedora 37, 36 and possibly 35, which are all end-of-life (since December 2023 in the case of Fedora 37).

Not affected: Fedora 38 (also EOL), 39 (maintained) and 40 (current).

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

#13

Post by meowface »

klysm wrote: post #7
candiddevmike wrote: post #5

The risk you take when you use a distribution that modifies upstream. Debian has had similar issues in the past (maybe not CVEs, but certainly packager-created bugs).

Debian has a fairly famous one: CVE-2008-0166

Ouch, that one's bad: https://github.com/g0tmi1k/debian-ssh#the-bug

>These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only "random" value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.

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

#14

Post by stncls »

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 stones -- glass houses and all. Also, this one is really like regreSSHion's little sibling. Still, easily finding the information I needed made me happy.)

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

#15

Post by Joker_vD »

klysm wrote: post #9
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?

Sounds reasonable, but since the language layer has no knowledge of signal handlers or what that means, it would be a separation of concerns problem. I'm sure you could get clang to do it, but still a tricky thing to design around. Ultimately it's an example of an invariant where it's clear that programmers can't be trusted to uphold it. In this case, the consequences can be very significant.

> the language layer has no knowledge of signal handlers or what that means

Despite the fact that there is explicit runtime support for signal handlers in the language runtime (i.e. libc).

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

#17

Post by bregma »

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 those insurmountable problems, yeah, good idea.

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

#18

Post by gruturo »

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…

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.

What should RedHat do, which does not:

1) make them lose their enterprise customers wanting a stable base

2) have unpatched security holes all over their distros

3) not cause them to backport stuff (we are here at the moment) ?

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

#19

Post by qalmakka »

gruturo wrote: post #18
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…

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?

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

#20

Post by AndyMcConachie »

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…

The author of the mail is Solar Designer, a bit of a legend AFAIC. He has no need to pump up his brand and he really really knows what he's doing.
Post reply on HN