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

https://jfrog.com/blog/openssh-pre-auth-double-free-cve-2023-25136-writeup-and-proof-of-concept/

by uraid • 3 years ago

161 86 3 years ago

jfrog.com

AdamJacobMuller• 3 years ago

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?

detourdog• 3 years ago

Needed fixing regardless and is fixed in 9.2.

uraid• 3 years ago

This is exploitable in the latest Archlinux 2023.02.01. Also, this doesn't require enabling old key exchange algorithms.

herpderperator• 3 years 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/

volkadav• 3 years ago

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.

mananaysiempre• 3 years 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

[2] https://github.com/archlinux/svntogit-packages/commit/796878...

aborsy• 3 years 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• 3 years ago

Yes. https://en.m.wikipedia.org/wiki/OpenBSD#Security_record

binkHN• 3 years ago

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• 3 years 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.

bawolff• 3 years ago

How else would trinity hack the power plant in the matrix!

px43• 3 years ago

Yup CVE-2001-0144

https://nvd.nist.gov/vuln/detail/CVE-2001-0144

https://www.youtube.com/watch?app=desktop&v=0PxTAn4g20U

LinuxBender• 3 years ago

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.

0x0• 3 years ago

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.

fgh• 3 years ago

Team TESO wrote an excellent exploit back in the day - one of the best groups of the early 2000s.

outworlder3• 3 years ago

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.

flatiron• 3 years ago

For else old folks it would be like WinNuke. Back in the day of dial up your entire PC was front and center on the internet. Windows 95 had a vulnerability that anyone could BSOD you. When it came out basically any IRC or multiplayer interaction you could get BSOD’d by any rando on the internet. I would be lying if I wasn’t occasionally on the sending end of these at the ripe old age of 12.

ranger_danger• 3 years ago

in certain cases crashes can be used to gain login access

surteen• 3 years 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.

acdha7• 3 years 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• 3 years 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.

userbinator• 3 years ago

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.

foobiekr• 3 years ago

On many systems, processes that are rapidly restarting or crashing tend to be throttled; depending on whether cores are enabled you can flood the system with core i/o. In addition, forking servers are often deliberately written to limit the fork frequency (fork bomb prevention).

st3fan• 3 years ago

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

speedgoose• 3 years ago

I expose Teleport instead of OpenSSH and it's not Rust but Golang.

outworlder3• 3 years ago

But OpenSSH is still in the picture, is it not?

yjftsjthsd-h• 3 years 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.

steponlego4• 3 years ago

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.

pdimitar12• 3 years ago

Advocating for better safety is spam, mmmkay. <takes notes>

redeeman• 3 years ago

haha yeah, there is a certain phrasing that just lights up from space... another similarity is the amount of projects written in go that just so happen to be "self contained in a single executable with no shared lib deps!!" (wonder why that is) :)

HybridCurve• 3 years ago

It's just spam at this point.

Yes, Can we be honest about this.

Promoting Rust by attacking C or other legacy languages that do not have equivalent memory safety is simply not constructive dialogue. Whenever the subject comes up concerning C/C++, or vulnerabilities discovered in common software packages someone always shows up to gripe about lack of memory safety in other language and then regurgitate the same litany of Rust vs C/C++ talking points. It gets old and it's not helping win over the developers the Rust community needs if they actually want to re-write the millions of lines code from the many open source projects to fix these problems.

The handful of Rust bros who show up to condemn C/C++ at every opportunity just make the Rust proponents look like a bunch of elitists, which is not fair to Rust or the community.

peoplefromibiza7• 3 years ago

Rewrite it in Rust. Only half joking

Waiting to put a star on your Github repo.

Maybe I even send $5 as a support for your work.

xvilka2• 3 years ago

See my comment about russh.

xvilka2• 3 years ago

There's russh[1][2]

[1] https://docs.rs/russh/latest/russh/

[2] https://github.com/warp-tech/russh

obituary_latte2• 3 years 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• 3 years 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... updated last december.

No need to rekey all accounts or servers, just switch to ecdsa or ed25519 progressively.

josephcsible2• 3 years 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• 3 years 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.

josephcsible2• 3 years ago

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.

obituary_latte2• 3 years ago

The reason it triggered my question is they had to do something similar to get the exploit to work (add +ssh-rsa to putty). Thanks, though, for the thoughtful reply.

jbverschoor2• 3 years ago

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

wolf550e• 3 years ago

What does your comment have to do with OpenSSH?

jbverschoor2• 3 years ago

OpenSSH, OpenSSL, same sort of new items.

dtx1• 3 years ago

If seeing software somewhere causes you anxiety, perhaps you should talk to a psychologist to help you overcome that.

somat• 3 years ago

Based on there respective track records I sometimes wish that shttp was a thing. http over ssh.

cesarb• 3 years 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

fulafel• 3 years 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?

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

Related Stories