[HN Gopher] OpenSSH Pre-Auth Double Free - Writeup and Proof-of-...
___________________________________________________________________
OpenSSH Pre-Auth Double Free - Writeup and Proof-of-Concept
Author : uraid
Score : 125 points
Date : 2023-02-08 17:34 UTC (5 hours ago)
(HTM) web link (jfrog.com)
(TXT) w3m dump (jfrog.com)
| AdamJacobMuller wrote:
| https://nvd.nist.gov/vuln/detail/CVE-2023-25136
|
| > OpenSSH server (sshd) 9.1 introduced
|
| 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?
| uraid wrote:
| This is exploitable in the latest Archlinux 2023.02.01. Also,
| this doesn't require enabling old key exchange algorithms.
| herpderperator wrote:
| 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/
| saghm wrote:
| 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.
| detourdog wrote:
| Needed fixing regardless and is fixed in 9.2.
| jbverschoor wrote:
| I repeat, "Every time I see OpenSSL anywhere I get this instant
| anxiety."
| wolf550e wrote:
| What does your comment have to do with OpenSSH?
| jbverschoor wrote:
| OpenSSH, OpenSSL, same sort of new items.
| [deleted]
| dtx1 wrote:
| If seeing software somewhere causes you anxiety, perhaps you
| should talk to a psychologist to help you overcome that.
| volkadav wrote:
| fwiw, fix available in openbsd patch
| 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.
| surteen wrote:
| _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 wrote:
| 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.
| userbinator wrote:
| You could just open the connections and let them sit
| _without_ crashing the process. Then those processes and
| connections will actually be consuming resources instead of
| crashing and disappearing.
| mike_hock wrote:
| ... up to MaxStartups. The most important resource they'd
| be consuming would be the startup slots.
| eklitzke wrote:
| 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.
| [deleted]
| aborsy wrote:
| 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!
| 0x0 wrote:
| Another example - where OpenSSH itself was not to blame, but
| rather PAM - was the old
| https://www.debian.org/security/2002/dsa-177
|
| Where locked accounts were treated as password-less accounts,
| and would allow direct ssh access.
|
| In Debian's defence, this was caught in the unstable distro and
| never made it out to a stable release.
| outworlder wrote:
| > I don't care about DoS or crashes!
|
| Be very, very concerned with any vulnerabilities that cause
| crashes. Someone may discover a way to control where the
| process points to, and now you have a way more serious issue.
| fgh wrote:
| Team TESO wrote an excellent exploit back in the day - one of
| the best groups of the early 2000s.
| loloquwowndueo wrote:
| Yes. https://en.m.wikipedia.org/wiki/OpenBSD#Security_record
| bawolff wrote:
| How else would trinity hack the power plant in the matrix!
| LinuxBender wrote:
| When that first showed in theaters in the bay area, people
| cheered and clapped _when she was using Nmap and SSH Nuke_.
| Non tech folks were probably a little confused.
| px43 wrote:
| Yup CVE-2001-0144
|
| https://nvd.nist.gov/vuln/detail/CVE-2001-0144
|
| https://www.youtube.com/watch?app=desktop&v=0PxTAn4g20U
| binkHN wrote:
| Per 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 wrote:
| 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.
| obituary_latte wrote:
| 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).
| [deleted]
| hartmel wrote:
| 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...
| updated last december.
|
| No need to rekey all accounts or servers, just switch to ecdsa
| or ed25519 progressively.
| josephcsible wrote:
| 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 wrote:
| 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.
| josephcsible wrote:
| > 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.
|
| No you don't. rsa-sha2-256 and rsa-sha2-512 are still enabled
| by default and can use the same key.
| crablover wrote:
| [flagged]
| 0xbadcafebee wrote:
| We'll just find exploits in the Rust implementation. A moved
| target is still a target.
| jamal-kumar wrote:
| If you're truly interested in this endeavour, there's some
| people who have a pretty good start on it who I think bear
| mention [1] [2] [3]
|
| For what it's worth "insisting on writing in C" for a large
| piece of software that's been a fundamental part of the secure
| internet for over 20 years now is just matter of momentum.
| We're talking having to redo the entire stack from the kernel
| to the drivers, ABI and up in a whole new programming language.
| It's being done, just keep in mind it's an enormous amount of
| work to get there.
|
| [1] https://www.redox-os.org/
|
| [2] https://github.com/RustCrypto/SSH
|
| [3] https://github.com/warp-tech/russh
| iueotnmunto wrote:
| quit spending your time talking about it and write a
| replacement then?
| jeltz wrote:
| 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?
| RealityVoid wrote:
| > Writing a security critical code base like that is not
| something everyone could or should do
|
| I mean... Why not? I know roll your own crypto is bad, but
| _someone_ has to do it. Might as well be you! Do it in the
| open, get feedback, attract high skill people to contribute
| to it and... Tadam! Cool codebase!
|
| I can't shake the feeling that making crypto as this
| magical thing people show ldnnot dream of is doing a
| disservice to us all.
| loloquwowndueo wrote:
| 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 wrote:
| Created an account 18 minutes ago to lecture everyone to
| develop in Rust :/
| fredoliveira wrote:
| Expected no less from someone named "crablover". If that
| person isn't going to lecture us all, who will?
| rastignack wrote:
| 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.
| IncRnd wrote:
| > You do not even know if the one you replied to is even a
| programmer.
|
| The person lectured, "The time is ripe for a Rust rewrite."
| People who read that comment would believe the author to be
| a programmer.
| [deleted]
| jmull wrote:
| > ...when you insist on writing your codebase in C
|
| It's not really a matter of "insisting". Suppose you start
| writing an open SSH tool for BSD in 1999. What language do you
| choose?
|
| Now that it's 2023 and OpenSSH in C is widely used, it's not as
| if it would be good if it were just abandoned (certainly not
| good from a security perspective). It makes sense for a team to
| continue maintaining it, right?
|
| There probably is a better language for an open SSH client.
| It's not going to write itself, though. This is open source.
| The interested people need to get together and figure out how
| to do it.
|
| It's just weird to me to imply the openssh people are doing
| something wrong when -- absent a time machine -- they clearly
| are not, and in fact are developing and maintaining a very
| valuable tool (probably aren't getting rich doing it, either).
| benibela wrote:
| >It's not really a matter of "insisting". Suppose you start
| writing an open SSH tool for BSD in 1999. What language do
| you choose?
|
| Pascal?
| [deleted]
| st3fan wrote:
| Rewrite it in Rust. Only half joking - this kind of critical
| infrastructure should not be written in C anymore.
| speedgoose wrote:
| I expose Teleport instead of OpenSSH and it's not Rust but
| Golang.
| outworlder wrote:
| But OpenSSH is still in the picture, is it not?
| duskwuff wrote:
| 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
| tptacek wrote:
| Teleport replaces OpenSSH.
| steponlego wrote:
| OpenBSD isn't switching away from C, and people are getting
| sick to their stomachs over the constant Rust "advocacy." It's
| just spam at this point.
| yjftsjthsd-h wrote:
| 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]
___________________________________________________________________
(page generated 2023-02-08 23:00 UTC)