OpenSSH Pre-Auth Double Free – Writeup and Proof-of-Concept | Hacker News Reader

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

jfrog.com

161 pointsuraid102 comments

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.

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

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!

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

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.

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.

Iirc the criticism was that the default install has no services enabled basically.

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.

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

Yup CVE-2001-0144

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

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

I remember people started probing pretty quickly, too, which was a good warning that you couldn’t be complacent about things like that. If memory serves, we’d upgraded most of our servers to only support SSH-2 before this happened and since that included our public shell servers (.edu) nobody broke in to anything but we did have to badger some proprietary vendors for updates to devices which were fortunately on our restricted internal-only network.

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.

There were dozens of us, dozens!

It was a relatively recent exploit, I remember being at an RSA conference when the remote ssh exploit was announced and everyone’s pager started going off and people hustled out of there. Fun times!

It's on their site too xD https://nmap.org/movies/

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.

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

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

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.

It could get much worse than a BSOD. Also from this era:

http://bash.org/?117002

in certain cases crashes can be used to gain login access

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.

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.

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.

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.

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.

... up to MaxStartups. The most important resource they'd be consuming would be the startup slots.

How many resources does that use, however? I’m not sure anything but an embedded device would even notice any of these possibilities. The closest I could come is Ubuntu’s old crash reporter but I thought they hardened that a while back.

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

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?

Needed fixing regardless and is fixed in 9.2.

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

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/

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.

> 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?

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

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

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

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

Teleport replaces OpenSSH.

Only if you deploy a teleport node, no? AFAIK it's optional

Feel free:) Once your replacement is fully functional, make sure to post it to HN so the rest of us know it's available.

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.

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

"Advocating for rust" and "Advocating for safety" are not the same thing and should never be confused as such.

They have an overlap. Your point? Apart from trying to act like a living breathing dictionary? Which apparently counts as a discussion technique?

I’m a huge fan of memory safety but if you’re going to hector other people about open source projects you should either be volunteering code or sending serious money.

Huh?

You mean if you find a bug, you're not allowed to point it out unless you have a PR ready that fixes it? Not sure what you're saying.

“You should rewrite your large C project” is not helpful unless you’re showing up to help.

“Here’s a specific bug you should fix” is different because it’s multiple orders of magnitude less work and doesn’t involve throwing out a ton of perfectly serviceable code.

Obviously actually helping right on the spot can be seen as more valuable, yes. In a perfect world.

In the world we live in, that's just not possible. Can you right every wrong you've ever witnessed?

Some of us see systemic and bigger problems and point those out. In your example it's fair to conclude "writing mission-critical code in C is an unjustified risk". Case in point, in a world where Heartbleed actually happened, that should've led to maintainers admitting that their language of choice isn't the right tool for the job.

As engineers we must be pragmatic. Yet many act like you're attacking their kids if you say "your programming language of choice is ill-suited for writing safe code".

This surprises me to this day, though I guess it really shouldn't. Like you, I imagine a perfect world.

> Some of us see systemic and bigger problems and point those out.

Consider whether this is more useful than saying “you know, you should probably find more time to go to the gym”. Anyone writing C code has heard this by now, and repetition probably isn’t going to help.

What could work is what we have seen successfully with Firefox, Linux, Chrome, Android, etc. where people didn’t demand a massive rewrite but instead showed up to work and picked something small where benefits could be seen quickly. Rust has excellent interoperability so you can do that well but you might run into challenges on projects like OpenSSH which have been ported to all kinds of obscure platforms.

(And, to be clear, I like Rust. It’s just I also understand open source maintainer burnout having had plenty of people suggest huge changes they thought were super important but still not enough that they personally wanted to help.)

I refuse to keep quiet unless I can do somebody's work for them.

Framing the whole thing like "saying C isn't cutting it anymore isn't a useful thing to say" is disingenuous.

As professionals we have to keep ourselves to higher standards. Currently I work in a company where the CTO said "screw you all" and forced a rewrite. And you know what? Recently we released the rewrite and it's going better and better each day.

These things do happen. Informed people with political capital to spend do exist.

It's a shame that the industry at large is mostly just comprised of followers.

(As for gradual rewrites, look at this thread. People are getting worked up just by saying the word "Rust". It's very sad but also kinda hilarious observing [supposed] adults act like that.)

Hey you should switch to my religion!

Trying to keep you from going to hell is spam? mmmkay. <takes notes>

Conflating "preaching" with "there are better ways to do the job" makes you unsuited to be an engineer.

Engineers are licensed and bonded. Are you licensed and bonded? No.

You didn't address the argument. You latched onto an imperfect analogy (and all analogues are imperfect). That tells me everything I need to know: you got no argument. You'll still seek to discredit the other side any way you can though, apparently.

You didn't even make an argument. Are you a licensed and bonded engineer?

I made arguments in this thread. You ignoring them and insisting on shifting the topic is disingenuous line of arguing.

Spelling it out for you: some safety is better than none. That was the topic. And that people call "cult" whatever they don't like in a very vain attempt to discredit it.

Try and keep up.

This is why Rust is toxic. This right here. It's unfortunate that an entire language is poisoned by too much dishonest advocacy but here we are. Nobody likes this disingenuous astroturf.

You don't like how I talk -- it's your right. But to ascribe some properties on an entire language and ecosystem, now that is a disingenuous astroturf.

yes. it is.

to the point that it has become cultism, if you're not being paid to spam

Ada is memory safe too.

Why not Ada?

Not enough libraries for what I had to do at the time. I looked at it.

Also you claiming something has "become" cultism does not make it a fact.

I'll go the other way around and say that your side in these discussions is the cult of "get off my lawn".

I'd equate you to the people who resisted the use of iron and concrete and claimed you can make tall buildings only out of wood. Anti-progress folks.

If it makes you sleep better then go for it. You're still wrong.

> Not enough libraries for what I had to do at the time. I looked at it.

have you ever considered the same is true for the hundreds of thousands of OSS projects out there that are writing their code in the language they know best and provides a wider range of opportunities?

If the advocacy for safe languages revolves only around _one_ language, it's spam.

It's the same thing of "excuse me sir do you have time to talk about our lord and savior Jesus Christ?"

There are so many imaginary godlike beings, why stop at the one?

> Also you claiming something has "become" cultism does not make it a fact.

spamming without being paid it's cultism.

It's the definition and it's not up for dispute.

> I'd equate you to the people who resisted the use of iron and concrete and claimed you can make tall buildings only out of wood. Anti-progress folks.

False premise.

I've never resisted to Rust, in fact I write Rust code when I need it.

Your argument is deeply flawed.

Because it comes from cultism, not from reasoning.

...according to you.

Whether somebody is spamming you, on a discussion forum that nobody holds a gun at your head to read, is very much up there in the air.

Claiming subjective feelings are facts is kindergarten stuff, I'm really interested how that's not obvious to an adult.

I write in 3 languages lately, Rust included, so stop trying to discredit what you dislike. People will keep pointing out Rust is a better fit for a number of projects and happily there's nothing you can do to stop it. Because it comes from experience and analysis, not cultism.

> ...according to you.

and many other people who have replied to the original message saying "enough with this Rust thing, we know, now write the code or STFU"

> I write in 3 languages lately, Rust included, so stop trying to discredit what you dislike

I literally said I write Rust too... and other 20 some languages.

maybe you're just too focused on accusing other people, instead of actually reading and understanding what they are trying to say to you?

Just like a cultist would do?

> People will keep pointing out Rust is a better fit for a number of projects and happily there's nothing you can do to stop it.

Saying and doing are 2 different things.

I can do one thing though: keep pointing out that cults are bad.

I said what I wanted to say, you simply repeating what you said before doesn't give it extra credibility, let future readers decide for themselves.

> you simply repeating what you said before doesn't give it extra credibility

it's not about credibility.

repetita iuvant.

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

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

> want to re-write the millions of lines code from the many open source projects

just nitpicking

it's billions.

at one LOC per second it would take 11.6 days to rewrite one million of them, but 32 years to rewrite a billion of them.

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

See my comment about russh.

has it been battle tested for years and has a very solid security track record though?

because that's what I want from an SSH client/server.

Like, yeah, this one's nice but

https://github.com/warp-tech/russh/issues/16

There's russh[1][2]

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

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

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

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.

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.

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.

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

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.

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

What does your comment have to do with OpenSSH?

OpenSSH, OpenSSL, same sort of new items.

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)

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

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

> 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

Reply on news.ycombinator.com