10 ms·

OpenSSH Pre-Auth Double Free – Writeup and Proof-of-Concept

161 points by uraid 4y ago

AdamJacobMuller 4y ago
https://nvd.nist.gov/vuln/detail/CVE-2023-25136 https://nvd.nist.gov/vuln/detail/CVE-2023-25136 > OpenSSH server (sshd) 9.1 introduced https://security-tracker.debian.org/tracker/CVE-2023-25136 https://security-tracker.debian.org/tracker/CVE-2023-25136 Is this even exploitable in any distributed configuration, considering that it requires enabling old deprecated key exchange algorithms?
- detourdog 4y ago
  Needed fixing regardless and is fixed in 9.2.
- uraid 4y ago
  This is exploitable in the latest Archlinux 2023.02.01. Also, this doesn't require enabling old key exchange algorithms.
  - herpderperator 4y ago
    What does "the latest Arch Linux" mean? Arch Linux is a rolling distribution. It was patched in the repository on 2023-02-02[0]. [0] https://archlinux.org/packages/core/x86_64/openssh/ https://archlinux.org/packages/core/x86_64/openssh/
    - saghm 4y ago
      I assume they mean the latest version available for download as an .iso, since I think that tends to happen around monthly. I agree that this isn't super concerning though, since even installing from that would result in an up-to-date system, and there isn't much reason to ssh to or from the live disk.
volkadav 4y ago
fwiw, fix available in openbsd patch https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/017_sshd.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/017_s... (run "doas syspatch" if you haven't in a while) spot checking, debian stable, ubuntu 22.04 lts and rhel 7/8/9 all ship pre-9.1 openssh which aren't affected, if that helps put anyone else's mind at ease a bit.
- mananaysiempre 4y ago
  This is already mentioned in a different comment here[1], but for ease of reference, Arch Linux did ship a vulnerable version and released the fix on 2 February[2]. [1] https://news.ycombinator.com/item?id=34713862 https://news.ycombinator.com/item?id=34713862 [2] https://github.com/archlinux/svntogit-packages/commit/79687856fe542fcbe722751d1314f105ede34863 https://github.com/archlinux/svntogit-packages/commit/796878...
aborsy 4y ago
Has OpenSSH ever had a vulnerability that has led to unauthorized login access? That would be a huge problem. I don’t care about DoS or crashes!
- loloquwowndueo 4y ago
  Yes. https://en.m.wikipedia.org/wiki/OpenBSD#Security_record https://en.m.wikipedia.org/wiki/OpenBSD#Security_record
- binkHN 4y ago
  Per http://www.openbsd.org http://www.openbsd.org, “Only two remote holes in the default install, in a heck of a long time!” I believe, at least one of these, was SSH related.
  - asveikau 4y ago
    They switched to "heck of a long time" because they had that blurb of text since the 90s. So we're talking about 2 holes in about 25 years. Though I think I heard some criticism of what counts and what does not for that tally, maybe 20 years ago. The project was fairly innovative of including now-standard practices like having the daemon drop its privileges.
    - bombcar 4y ago
      Iirc the criticism was that the default install has no services enabled basically.
      - IcePic 4y ago
        Yeah, people in the 90s really loved installing redhat 4 (not rhel 4, the old versions) and getting a vulnerable pop2/pop3/imapd running by default after installs. You would get hacked within the hour if not behind firewalls. Very unfair of OpenBSD (and other security conscious OSes) to not compete on equal terms there.
- 4y ago
crablover 4y ago
[flagged]
- iueotnmunto 4y ago
  quit spending your time talking about it and write a replacement then?
  - jeltz 4y ago
    Writing a security critical code base like that is not something everyone could or should do. You do not even know if the one you replied to is even a programmer. Should the start university and study computer engineering and then specialize in cryptography and then finally write the library?
    - loloquwowndueo 4y ago
      But if not a programmer or knowledgeable about crypto they definitely should shut up about how Rust will save us all from all bugs for all eternity :)
      - jamespo 4y ago
        Created an account 18 minutes ago to lecture everyone to develop in Rust :/
        fredoliveira 4y ago
        Expected no less from someone named "crablover". If that person isn't going to lecture us all, who will?
    - rastignack 4y ago
      The first step would be to bless as much as possible of rust-crypto and promote it to Stdlib. I sometimes wish the rust foundation would hire someone who does for rust what Filippo Valsorda does for go.
surteen 4y ago
The JFrog Security Research team gave this vulnerability a Medium severity rating for the following reasons: A DoS attack that crashes a forked worker process is much less severe than a DoS that crashes an important daemon, but they will both receive a “High” Availability impact CVSS rating. How is this even considered a DoS at all? You're forking a process and then immediately crashing it. You're only Denying Service to your own connection that you just made.
- acdha 4y ago
  I agree that this is pretty limited. I think that depends on how expensive it is to create a process: if you could open enough connections or hit something like the audit log frequently enough[1], it might be a decent traffic multiplier when you can't otherwise do something damaging (maybe in a scenario where you get something like a r/o deploy key?). 1. I'm not sure this is very useful but I was thinking that if someone follows one of the security hardening standards, their servers are configured to hang until the audit log buffer can be flushed but you could more easily hit that by failed login requests unless they have something like fail2ban installed.
  - eklitzke 4y ago
    As you pointed out it's a DOS in the sense that causing a process to fork/crash is much more expensive than a regular denied connection, so it would be easier for an attacker to overload the server using this technique than it would be if they were just making regular denied connections. Also consider that on many systems this would trigger a core dump which will cause a few MB to be written to disk (although you probably can't fill up the disk because in the default configuration most systems are configured to keep either just one core dump or N, where N is some small number like 10). I think the audit log stuff is a red herring because regular denied connections are already written to the audit log.
    - acdha 4y ago
      Does anything have core dumps enabled by default any more? I thought about that but it’s been years (decades?) since I encountered it unintentionally.
deleted 4y ago
[deleted]
st3fan 4y ago
Rewrite it in Rust. Only half joking - this kind of critical infrastructure should not be written in C anymore.
- speedgoose 4y ago
  I expose Teleport instead of OpenSSH and it's not Rust but Golang.
  - outworlder 4y ago
    But OpenSSH is still in the picture, is it not?
    - duskwuff 4y ago
      I'm not specifically familiar with Teleport, but Go has its own native SSH implementation which doesn't depend on OpenSSH: https://pkg.go.dev/golang.org/x/crypto/ssh https://pkg.go.dev/golang.org/x/crypto/ssh
    - tptacek 4y ago
      Teleport replaces OpenSSH.
      - outworlder 4y ago
        Only if you deploy a teleport node, no? AFAIK it's optional
- yjftsjthsd-h 4y ago
  Feel free:) Once your replacement is fully functional, make sure to post it to HN so the rest of us know it's available.
- deleted 4y ago
  [deleted]
- steponlego 4y ago
obituary_latte 4y ago
I upgraded my Mac to Monterey the other day and all of a sudden all of my SSH connections would not work any more. After some digging, I came across a solution where adding Host hostnameOrIPaddress HostKeyAlgorithms +ssh-rsa PubKeyAcceptedKeyTypes +ssh-rsa to ~/.ssh/config fixed the issue. I'm wondering if doing this makes me more vulnerable? Or is bad practice somehow? NB: using iTerm2 3.5.0beta9 and Oh My Zsh master (a1c54e0).
- hartmel 4y ago
  Edit: my bad, +ssh-rsa refers to a signature algorithm using SHA1, which should not be used anymore. Target server host keys should be renewed, as told by riolu, thanks to him for pointing it. On debian-like, remove host keys and run dpkg-configure openssh-server. On redhat-like, remove host keys and restart sshd. --------------------------------------------- Not vulnerable, not a bad practice. Newer algorithms are faster (in practice not perceptible, people usually don't need state of the art performance for SSH connections), with smaller keys and probably better algorithms (not subject to side channel attacks, which are still hard to abuse) but RSA is not broken. It may be in a few years with quantum computing but it's still far to be sure. https://www.schneier.com/blog/archives/2021/03/no-rsa-is-not-broken.html https://www.schneier.com/blog/archives/2021/03/no-rsa-is-not... updated last december. No need to rekey all accounts or servers, just switch to ecdsa or ed25519 progressively.
  - josephcsible 4y ago
    That change isn't actually about RSA vs. ECC. It's about SHA-1 vs. SHA-2. The default configuration still supports using your existing RSA keys, but with a different hashing algorithm (with the options rsa-sha2-256 and rsa-sha2-512). That configuration change allows use of SHA-1 to continue.
- riolu 4y ago
  That isn't even remotely related the post and Monterey is over a year old. The systems you are trying to SSH to are using outdated host keys, you need to actually update to get security fixes, it will regenerate host keys. You shouldn't be worried about this CVE, it sounds like you have quite a few years of CVE's you've neglected to patch anyways.
jbverschoor 4y ago
I repeat, "Every time I see OpenSSL anywhere I get this instant anxiety."
- deleted 4y ago
  [deleted]
- wolf550e 4y ago
  What does your comment have to do with OpenSSH?
  - jbverschoor 4y ago
    OpenSSH, OpenSSL, same sort of new items.
    - IntelMiner 4y ago
      What? No OpenSSH and OpenSSL are completely different projects run by completely different people Hell, The OpenBSD folks had a "fun" time forking OpenSSL to create "LibreSSL" (before it was promptly ignored by the rest of the open source community unfortunately)
- dtx1 4y ago
  If seeing software somewhere causes you anxiety, perhaps you should talk to a psychologist to help you overcome that.
- somat 4y ago
  Based on there respective track records I sometimes wish that shttp was a thing. http over ssh.
  - cesarb 4y ago
    > Based on there respective track records I sometimes wish that shttp was a thing. Well, shttp was a thing: https://www.rfc-editor.org/rfc/rfc2660.html https://www.rfc-editor.org/rfc/rfc2660.html
deleted 4y ago
[deleted]
fulafel 4y ago
> Though remote code execution is theoretically possible, it would require deep-dive research for finding allocation primitives, and even then- will be less impactful because of its security measures. On the face of it this seems quite lenient. Seems like the only thing holding the gate from preauth ssh rce is the sandbox now, how confident are we about it?

161 points by uraid 4y ago

https://nvd.nist.gov/vuln/detail/CVE-2023-25136 https://nvd.nist.gov/vuln/detail/CVE-2023-25136 > OpenSSH server (sshd) 9.1 introduced https://security-tracker.debian.org/tracker/CVE-2023-25136 https://security-tracker.debian.org/tracker/CVE-2023-25136 Is this even exploitable in any distributed configuration, considering that it requires enabling old deprecated key exchange algorithms?

detourdog 4y ago
Needed fixing regardless and is fixed in 9.2.
uraid 4y ago
This is exploitable in the latest Archlinux 2023.02.01. Also, this doesn't require enabling old key exchange algorithms.
- herpderperator 4y ago
  What does "the latest Arch Linux" mean? Arch Linux is a rolling distribution. It was patched in the repository on 2023-02-02[0]. [0] https://archlinux.org/packages/core/x86_64/openssh/ https://archlinux.org/packages/core/x86_64/openssh/
  - saghm 4y ago
    I assume they mean the latest version available for download as an .iso, since I think that tends to happen around monthly. I agree that this isn't super concerning though, since even installing from that would result in an up-to-date system, and there isn't much reason to ssh to or from the live disk.

volkadav 4y ago

fwiw, fix available in openbsd patch https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/017_sshd.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/017_s... (run "doas syspatch" if you haven't in a while) spot checking, debian stable, ubuntu 22.04 lts and rhel 7/8/9 all ship pre-9.1 openssh which aren't affected, if that helps put anyone else's mind at ease a bit.

mananaysiempre 4y ago
This is already mentioned in a different comment here[1], but for ease of reference, Arch Linux did ship a vulnerable version and released the fix on 2 February[2]. [1] https://news.ycombinator.com/item?id=34713862 https://news.ycombinator.com/item?id=34713862 [2] https://github.com/archlinux/svntogit-packages/commit/79687856fe542fcbe722751d1314f105ede34863 https://github.com/archlinux/svntogit-packages/commit/796878...

aborsy 4y ago

Has OpenSSH ever had a vulnerability that has led to unauthorized login access? That would be a huge problem. I don’t care about DoS or crashes!

loloquwowndueo 4y ago
Yes. https://en.m.wikipedia.org/wiki/OpenBSD#Security_record https://en.m.wikipedia.org/wiki/OpenBSD#Security_record
binkHN 4y ago
Per http://www.openbsd.org http://www.openbsd.org, “Only two remote holes in the default install, in a heck of a long time!” I believe, at least one of these, was SSH related.
- asveikau 4y ago
  They switched to "heck of a long time" because they had that blurb of text since the 90s. So we're talking about 2 holes in about 25 years. Though I think I heard some criticism of what counts and what does not for that tally, maybe 20 years ago. The project was fairly innovative of including now-standard practices like having the daemon drop its privileges.
  - bombcar 4y ago
    Iirc the criticism was that the default install has no services enabled basically.
    - IcePic 4y ago
      Yeah, people in the 90s really loved installing redhat 4 (not rhel 4, the old versions) and getting a vulnerable pop2/pop3/imapd running by default after installs. You would get hacked within the hour if not behind firewalls. Very unfair of OpenBSD (and other security conscious OSes) to not compete on equal terms there.
4y ago

crablover 4y ago

[flagged]

iueotnmunto 4y ago
quit spending your time talking about it and write a replacement then?
- jeltz 4y ago
  Writing a security critical code base like that is not something everyone could or should do. You do not even know if the one you replied to is even a programmer. Should the start university and study computer engineering and then specialize in cryptography and then finally write the library?
  - loloquwowndueo 4y ago
    But if not a programmer or knowledgeable about crypto they definitely should shut up about how Rust will save us all from all bugs for all eternity :)
    - jamespo 4y ago
      Created an account 18 minutes ago to lecture everyone to develop in Rust :/
      - fredoliveira 4y ago
        Expected no less from someone named "crablover". If that person isn't going to lecture us all, who will?
  - rastignack 4y ago
    The first step would be to bless as much as possible of rust-crypto and promote it to Stdlib. I sometimes wish the rust foundation would hire someone who does for rust what Filippo Valsorda does for go.

surteen 4y ago

The JFrog Security Research team gave this vulnerability a Medium severity rating for the following reasons: A DoS attack that crashes a forked worker process is much less severe than a DoS that crashes an important daemon, but they will both receive a “High” Availability impact CVSS rating. How is this even considered a DoS at all? You're forking a process and then immediately crashing it. You're only Denying Service to your own connection that you just made.

acdha 4y ago
I agree that this is pretty limited. I think that depends on how expensive it is to create a process: if you could open enough connections or hit something like the audit log frequently enough[1], it might be a decent traffic multiplier when you can't otherwise do something damaging (maybe in a scenario where you get something like a r/o deploy key?). 1. I'm not sure this is very useful but I was thinking that if someone follows one of the security hardening standards, their servers are configured to hang until the audit log buffer can be flushed but you could more easily hit that by failed login requests unless they have something like fail2ban installed.
- eklitzke 4y ago
  As you pointed out it's a DOS in the sense that causing a process to fork/crash is much more expensive than a regular denied connection, so it would be easier for an attacker to overload the server using this technique than it would be if they were just making regular denied connections. Also consider that on many systems this would trigger a core dump which will cause a few MB to be written to disk (although you probably can't fill up the disk because in the default configuration most systems are configured to keep either just one core dump or N, where N is some small number like 10). I think the audit log stuff is a red herring because regular denied connections are already written to the audit log.
  - acdha 4y ago
    Does anything have core dumps enabled by default any more? I thought about that but it’s been years (decades?) since I encountered it unintentionally.

deleted 4y ago

[deleted]

st3fan 4y ago

Rewrite it in Rust. Only half joking - this kind of critical infrastructure should not be written in C anymore.

speedgoose 4y ago
I expose Teleport instead of OpenSSH and it's not Rust but Golang.
- outworlder 4y ago
  But OpenSSH is still in the picture, is it not?
  - duskwuff 4y ago
    I'm not specifically familiar with Teleport, but Go has its own native SSH implementation which doesn't depend on OpenSSH: https://pkg.go.dev/golang.org/x/crypto/ssh https://pkg.go.dev/golang.org/x/crypto/ssh
  - tptacek 4y ago
    Teleport replaces OpenSSH.
    - outworlder 4y ago
      Only if you deploy a teleport node, no? AFAIK it's optional
yjftsjthsd-h 4y ago
Feel free:) Once your replacement is fully functional, make sure to post it to HN so the rest of us know it's available.
deleted 4y ago
[deleted]
steponlego 4y ago

obituary_latte 4y ago

I upgraded my Mac to Monterey the other day and all of a sudden all of my SSH connections would not work any more. After some digging, I came across a solution where adding Host hostnameOrIPaddress HostKeyAlgorithms +ssh-rsa PubKeyAcceptedKeyTypes +ssh-rsa to ~/.ssh/config fixed the issue. I'm wondering if doing this makes me more vulnerable? Or is bad practice somehow? NB: using iTerm2 3.5.0beta9 and Oh My Zsh master (a1c54e0).

hartmel 4y ago
Edit: my bad, +ssh-rsa refers to a signature algorithm using SHA1, which should not be used anymore. Target server host keys should be renewed, as told by riolu, thanks to him for pointing it. On debian-like, remove host keys and run dpkg-configure openssh-server. On redhat-like, remove host keys and restart sshd. --------------------------------------------- Not vulnerable, not a bad practice. Newer algorithms are faster (in practice not perceptible, people usually don't need state of the art performance for SSH connections), with smaller keys and probably better algorithms (not subject to side channel attacks, which are still hard to abuse) but RSA is not broken. It may be in a few years with quantum computing but it's still far to be sure. https://www.schneier.com/blog/archives/2021/03/no-rsa-is-not-broken.html https://www.schneier.com/blog/archives/2021/03/no-rsa-is-not... updated last december. No need to rekey all accounts or servers, just switch to ecdsa or ed25519 progressively.
- josephcsible 4y ago
  That change isn't actually about RSA vs. ECC. It's about SHA-1 vs. SHA-2. The default configuration still supports using your existing RSA keys, but with a different hashing algorithm (with the options rsa-sha2-256 and rsa-sha2-512). That configuration change allows use of SHA-1 to continue.
riolu 4y ago
That isn't even remotely related the post and Monterey is over a year old. The systems you are trying to SSH to are using outdated host keys, you need to actually update to get security fixes, it will regenerate host keys. You shouldn't be worried about this CVE, it sounds like you have quite a few years of CVE's you've neglected to patch anyways.

jbverschoor 4y ago

I repeat, "Every time I see OpenSSL anywhere I get this instant anxiety."

deleted 4y ago
[deleted]
wolf550e 4y ago
What does your comment have to do with OpenSSH?
- jbverschoor 4y ago
  OpenSSH, OpenSSL, same sort of new items.
  - IntelMiner 4y ago
    What? No OpenSSH and OpenSSL are completely different projects run by completely different people Hell, The OpenBSD folks had a "fun" time forking OpenSSL to create "LibreSSL" (before it was promptly ignored by the rest of the open source community unfortunately)
dtx1 4y ago
If seeing software somewhere causes you anxiety, perhaps you should talk to a psychologist to help you overcome that.
somat 4y ago
Based on there respective track records I sometimes wish that shttp was a thing. http over ssh.
- cesarb 4y ago
  > Based on there respective track records I sometimes wish that shttp was a thing. Well, shttp was a thing: https://www.rfc-editor.org/rfc/rfc2660.html https://www.rfc-editor.org/rfc/rfc2660.html

deleted 4y ago

[deleted]

fulafel 4y ago

> Though remote code execution is theoretically possible, it would require deep-dive research for finding allocation primitives, and even then- will be less impactful because of its security measures. On the face of it this seems quite lenient. Seems like the only thing holding the gate from preauth ssh rce is the sandbox now, how confident are we about it?