8 ms·

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

141 points by andreyv 2y ago

abdil07 2y ago
[flagged]
crest 2y ago
It's almost as if you should understand security critical C code before you start patching it to death.
- deleted 2y ago
  [deleted]
hannob 2y ago
For clarification, the bug is in a patch applied by red hat, not in openssh itself.
- bonzini 2y ago
  Technically the bug is in upstream code, but it is latent without the Red Hat patch: > cleanup_exit() was not meant to be called from a signal handler [...] Fedora 38+ has moved to newer upstream OpenSSH that doesn't have the problematic cleanup_exit() call. > This extra problematic logic only existed in upstream OpenSSH(-portable) for ~9 months The fix also doesn't touch the Red Hat-specific code: diff -urp openssh-8.7p1-38.el9_4.1-tree.orig/sshd.c openssh-8.7p1-38.el9_4.1-tree/sshd.c --- openssh-8.7p1-38.el9_4.1-tree.orig/sshd.c 2024-07-08 03:42:51.431994307 +0200 +++ openssh-8.7p1-38.el9_4.1-tree/sshd.c 2024-07-08 03:48:13.860316451 +0200 @@ -384,7 +384,7 @@ grace_alarm_handler(int sig) /* Log error and exit. */ if (use_privsep && pmonitor != NULL && pmonitor->m_pid <= 0) - cleanup_exit(255); /* don't log in privsep child */ + _exit(1); /* don't log in privsep child */ else { sigdie("Timeout before authentication for %s port %d", ssh_remote_ipaddr(the_active_state), They suggest applying it even on non Red Hat distros.
- loeg 2y ago
  Sort of. The upstream bug isn't thought to be exploitable alone.
ta988 2y ago
My understanding here is that it only impacts Redhat (and maybe derivatives)?
- stncls 2y ago
  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).
londons_explore 2y ago
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?
- klysm 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - Joker_vD 2y ago
    > 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).
    - sqeaky 2y ago
      Yep, such is C.
    - ori_b 2y ago
      Libc isn't the language runtime. The runtime is '/use/lib/crt*.o', which has no concept at all of signal handling. Libc isn't particularly intrinsic to the language, and outside of some assembly to make syscalls, you can implement an alternative with a completely different interface, purely in C.
      - SAI_Peregrinus 2y ago
        The language standard library does, however, contain explicit support for signal handling, as specified in ISO/IEC 1989:2023 section 7.14 Signal handling <signal.h>. The cross-platform bits of libc are specified in the C standard. The POSIX-specific bits are specified by the Open Group in the POSIX standard. The OS-specific bits are specified by the OS and implemented by whoever is writing the libc in question. A libc is a sort of statically linked combination of the C standard library and some OS-specific standard library extensions.
candiddevmike 2y ago
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).
- klysm 2y ago
  Debian has a fairly famous one: CVE-2008-0166
  - meowface 2y ago
    Ouch, that one's bad: https://github.com/g0tmi1k/debian-ssh#the-bug 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.
  - rlpb 2y ago
    In that particular case upstream _was_ consulted and had acked the patch.
    - immibis 2y ago
      Upstream was consulted for a similar change in another location, where the code was actually unnecessary.
- 2OEH8eoCRo0 2y ago
  It's risks all the way down. There are risks to not patching upstream as well.
qalmakka 2y ago
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.
- gruturo 2y ago
  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) ?
  - qalmakka 2y ago
    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?
    - sqeaky 2y ago
      C isn't magic, plenty of people understand it and lots of these projects move quite slow. That these things CVEs on ssh are so rare shows how well this process normally works. These past couple of weeks have had 3(?) ssh vulnerabilities? We often go years with one, and not all are a result of packaging some come from upstream. Any new process needs to not just fix this problem, but also all or at least most of the problems that the existing processes fixes.
stncls 2y ago
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.)
- AndyMcConachie 2y ago
  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.
  - formerly_proven 2y ago
    Yeah. He created openwall and the oss-security list.
- tptacek 2y ago
  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.
  - ericpauley 2y ago
    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.
    - tptacek 2y ago
      The whole point of naming vulnerabilities is to establish a vernacular about them, so it's not surprising that academic papers name them. The literature about hardware microarchitectural attacks, for instance, would be fucking inscrutable (even more than it is now) without the names.
password4321 2y ago
Is this in any way related to CVE-2024-6387 "RegreSSHion" discussed last week? https://news.ycombinator.com/item?id=40843778 https://news.ycombinator.com/item?id=40843778 Edit: Ok it seems very closely related; I was just surprised no one had linked the previous discussion.

141 points by andreyv 2y ago

abdil07 2y ago

[flagged]

crest 2y ago

It's almost as if you should understand security critical C code before you start patching it to death.

deleted 2y ago
[deleted]

hannob 2y ago

For clarification, the bug is in a patch applied by red hat, not in openssh itself.

bonzini 2y ago
Technically the bug is in upstream code, but it is latent without the Red Hat patch: > cleanup_exit() was not meant to be called from a signal handler [...] Fedora 38+ has moved to newer upstream OpenSSH that doesn't have the problematic cleanup_exit() call. > This extra problematic logic only existed in upstream OpenSSH(-portable) for ~9 months The fix also doesn't touch the Red Hat-specific code: diff -urp openssh-8.7p1-38.el9_4.1-tree.orig/sshd.c openssh-8.7p1-38.el9_4.1-tree/sshd.c --- openssh-8.7p1-38.el9_4.1-tree.orig/sshd.c 2024-07-08 03:42:51.431994307 +0200 +++ openssh-8.7p1-38.el9_4.1-tree/sshd.c 2024-07-08 03:48:13.860316451 +0200 @@ -384,7 +384,7 @@ grace_alarm_handler(int sig) /* Log error and exit. */ if (use_privsep && pmonitor != NULL && pmonitor->m_pid <= 0) - cleanup_exit(255); /* don't log in privsep child */ + _exit(1); /* don't log in privsep child */ else { sigdie("Timeout before authentication for %s port %d", ssh_remote_ipaddr(the_active_state), They suggest applying it even on non Red Hat distros.
loeg 2y ago
Sort of. The upstream bug isn't thought to be exploitable alone.

ta988 2y ago

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

stncls 2y ago
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).

londons_explore 2y ago

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?

klysm 2y ago
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.
- deleted 2y ago
  [deleted]
- Joker_vD 2y ago
  > 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).
  - sqeaky 2y ago
    Yep, such is C.
  - ori_b 2y ago
    Libc isn't the language runtime. The runtime is '/use/lib/crt*.o', which has no concept at all of signal handling. Libc isn't particularly intrinsic to the language, and outside of some assembly to make syscalls, you can implement an alternative with a completely different interface, purely in C.
    - SAI_Peregrinus 2y ago
      The language standard library does, however, contain explicit support for signal handling, as specified in ISO/IEC 1989:2023 section 7.14 Signal handling <signal.h>. The cross-platform bits of libc are specified in the C standard. The POSIX-specific bits are specified by the Open Group in the POSIX standard. The OS-specific bits are specified by the OS and implemented by whoever is writing the libc in question. A libc is a sort of statically linked combination of the C standard library and some OS-specific standard library extensions.

candiddevmike 2y ago

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

klysm 2y ago
Debian has a fairly famous one: CVE-2008-0166
- meowface 2y ago
  Ouch, that one's bad: https://github.com/g0tmi1k/debian-ssh#the-bug 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.
- rlpb 2y ago
  In that particular case upstream _was_ consulted and had acked the patch.
  - immibis 2y ago
    Upstream was consulted for a similar change in another location, where the code was actually unnecessary.
2OEH8eoCRo0 2y ago
It's risks all the way down. There are risks to not patching upstream as well.

qalmakka 2y ago

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.

gruturo 2y ago
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) ?
- qalmakka 2y ago
  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?
  - sqeaky 2y ago
    C isn't magic, plenty of people understand it and lots of these projects move quite slow. That these things CVEs on ssh are so rare shows how well this process normally works. These past couple of weeks have had 3(?) ssh vulnerabilities? We often go years with one, and not all are a result of packaging some come from upstream. Any new process needs to not just fix this problem, but also all or at least most of the problems that the existing processes fixes.

stncls 2y ago

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

AndyMcConachie 2y ago
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.
- formerly_proven 2y ago
  Yeah. He created openwall and the oss-security list.
tptacek 2y ago
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.
- ericpauley 2y ago
  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.
  - tptacek 2y ago
    The whole point of naming vulnerabilities is to establish a vernacular about them, so it's not surprising that academic papers name them. The literature about hardware microarchitectural attacks, for instance, would be fucking inscrutable (even more than it is now) without the names.

password4321 2y ago

Is this in any way related to CVE-2024-6387 "RegreSSHion" discussed last week? https://news.ycombinator.com/item?id=40843778 https://news.ycombinator.com/item?id=40843778 Edit: Ok it seems very closely related; I was just surprised no one had linked the previous discussion.