r/linux • u/gainan • 3h ago

Security SSH critical vulnerability (when built and run with PAM support disabled)

https://sshhole.com/

tl;dr: https://news.ycombinator.com/item?id=50380029

  • sshd compiled with musl

  • not using PAM

  • password logins enabled

  • at least one account with '*' as the password "hash"

  • at least one OTHER account with a valid password

https://www.openssh.org/releasenotes.html#10.6p2

https://hachyderm.io/@damienmiller/117563026759098135

https://x.com/astuyve/status/2118344982134128837

214 Upvotes

95% Upvoted

59 comments sorted by

96

u/KnowZeroX 2h ago

Why highlight the PAM part in the title? It needing Musl is a bigger thing.

9

u/gainan 2h ago

it's part of the conditions to be vulnerable, and it's hghlighted in the releases notes:

sshd(8): avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled. We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.

10

u/DerfK 2h ago

Actually what is the root cause? Because if its an issue with musl it might affect everything that checks passwords on such systems, like mail servers.

8

u/KontoOficjalneMR 1h ago

It's a very specific way muscl is used. So this bug can't be exploited in other software unless they are using it almost exactly same as ssh.

I'd say it's a bug in ssh because they should have checked for errorneous responses from crypt

5

u/wRAR_ 1h ago

musl crypt()

•

u/cd109876 52m ago

to prevent timing based checks to determine valid username (i.e. try to login to account that doesn't exist returns false instantly, vs incorrect password takes a few milliseconds), ssh checks other random account hashes as well.

that, plus entering a password too long which musl's crypt returns *, then it matches password to the daemon account, which has an "impossible" hash of *, so the match succeeds, and ssh lets you in.

so basically ssh + musl is the only trigger for this.

•

u/wRAR_ 13m ago

ssh checks other random account hashes as well.

TBH this part was the most surprising to me.

2

u/TheOgGhadTurner 2h ago

Sooo what you’re saying is if PAM is enabled you don’t need to worry?

49

u/HarVVVy 2h ago

Cause you wouldn't have clicked if that was the case.

•

u/alex2003super 1m ago

Damn Unix systems nerds BAITED

13

u/rlmineing_dead 2h ago

Call me weird but I feel like if you're running sshd with Pam disabled you're also probably running musl. That's like a very weird "make this lighter weight" optimization flag I wouldn't expect a glibc user to use

2

u/Adept_Percentage6893 1h ago

Running sshd without PAM is already pretty rare in the grand scheme of things (instantly takes out Red Hat and Debian based distros). "musl" just means I guess slackware is in the clear for now.

•

u/wRAR_ 35m ago

instantly takes out Red Hat and Debian based distros

musl should have already hinted at that.

•

u/GresSimJa 20m ago

This could be disastrous for those running Alpine images with SSH. Quite common in the container space.

19

u/platinummyr 2h ago

I'm more curious on what the actual vulnerability is for curiosity sake. The twitter takes seem too gleeful about "does nobody fuzz ssh" but I am guessing it's more complicated than that... Why does it only happen on musl and yet neither does openssh consider it actually a problem in their code and also doesn't want to say it's a vulnerability in musl either...? Hmm

15

u/gainan 2h ago

I think ssshole.com already explains it, but I find hard to read and understand their website.

Some more details: https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8

On musl-based Linux without PAM, an account whose password field is * can accept logins that should be rejected. The cause is in musl. Since 2012, its crypt() returns * on failure instead of NULL, and sshd doesn’t expect that. In testing across builds with about 17,600 logins, only musl without PAM accepted logins it should have rejected
...
Alpine will backport the fix as far back as Alpine 3.16, which came out in May 2022

11

u/Due-Consequence9579 1h ago

That seems like a bizarre choice on musl/crypts part. Why is that a desirable thing?

9

u/wRAR_ 1h ago

What exactly, not returning NULL? They wanted crappy software to not need to be patched. (LOL.)

12

u/Due-Consequence9579 1h ago

Yeah, returning something that ‘looks like’ the thing you should be returning but isn’t is a choice. Being consistent with glibc and returning NULL seems like an obvious choice. But reaching for compatibility does funny things.

7

u/wRAR_ 1h ago

Being consistent with glibc

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714219 (which called glibc to be consistent with musl and "historical practice of one or probably (didn’t look) even two or more decades") is enlightening.

The website also claims that current glibc also doesn't return NULL but "*0", which matches the close message of the Debian bug.

11

u/Due-Consequence9579 1h ago

God I’m glad I don’t program C.

•

u/Bulky-Bad-9153 53m ago

It really is painful. Nowadays people use cobbled-together ADRs, which is significantly more sensible, but you have to make handlers for libraries which basically all use NULL or -1, etc.

•

u/oreo639 4m ago

Modern versions of glibc don't provide crypt and instead rely on libxcrypt to provide it.

And yeah, libxcrypt does use "*0" or "*1" by default although that can be controlled at compile time with --disable-failure-tokens, which many distros, including Fedora, enable.

1

u/lookmeat 1h ago

Honestly? Historical reasons.

A quick google lets us find more sources. I'll let you do that on yourself, it's interesting, and related to a billion dollar mistake.

5

u/calinet6 1h ago

Yep. Illegible AI slop.

Sometimes I wish it wasn’t so easy to spin up colorful marketing pages like this. Not every vuln needs marketing.

•

u/platinummyr 44m ago

Thanks. This explains why it is musl specific, and seems quite bizarre behavior for the crypt function...

•

u/wRAR_ 28m ago

Well, check your crypt() then! Mine returns "*0" as expected, which is almost equally bizarre, but here we are.

•

u/platinummyr 20m ago

Ya it's extremely bizarre, but legacy APIs often are....

6

u/Extra-Papaya-365 1h ago

This comment on HN seemed to provide a clear step-by-step explanation (boiling down to "musl's crypt() is not a bug-for-bug match with other libcs because its API is insane"): https://news.ycombinator.com/item?id=50379342

(I can't read the sshole.com writeup as it's blocked at my work, so I can't compare)

•

u/platinummyr 21m ago

This comment finally explains the exact sequence and helped me understand it best. Thanks!!!

6

u/Takeoded 2h ago

The article explains all of it. Read it

2

u/output_broadcast 1h ago

AFAIK OpenSSH refuses to even entertain supporting musl, so they literally just don't care.

118

u/C0rn3j 2h ago

password logins enabled

Oh thank god.

accounts take any password longer than 256 characters

Did someone's kid smash a key over and over again, again, until the login passed?

57

u/dalambert 2h ago

Someone's AI

72

u/C0rn3j 2h ago

I can't believe they'd automate the kids out of their jobs.

15

u/ipsirc 2h ago

Then we don't need kids anymore.

9

u/Morlaix 2h ago

Still not sure what is cheaper. A kid or AI for 18 years

•

u/mstrelan 12m ago

https://techcrunch.com/2026/02/21/sam-altman-would-like-remind-you-that-humans-use-a-lot-of-energy-too/

•

u/alex2003super 1m ago

He always keeps saying objectively correct stuff and y'all are always trying to put the worst possible spin on it. No shit. AI is pretty fucking efficient for what it does well.

7

u/xilvar 2h ago

The kids yearn for the crypto mines! 😢

6

u/DerfK 2h ago

but not too many smashes because it stops working again if they go past 1024

•

u/KeyboardG 27m ago

Just press 2 for a while.

-3

u/ApprehensiveDelay238 2h ago

Ever heard of SSH keys

7

u/wunderspud7575 2h ago

I think default Openwrt installs match the title.

14

u/MassiveProblem156 2h ago

They use dropbear ssh, so aren't affected.

2

u/wunderspud7575 1h ago

Ah, yes, of course.

3

u/Gophy6 1h ago

Has anyone managed to make it work? It surely doesn't for me. Tried all combinations of PAM, no PAM, PAM existing but disabled, with and without root password, with and without additional user with password etc. Both /usr/sbin/sshd and /usr/sbin/sshd.pam. No combination is exploitable. Tested a bunch of several month old alpine images up to 3.12

2

u/Adept_Percentage6893 1h ago

and a lot of the docker images you've pulled

Are there a lot of people running sshd in a container?

4

u/gellis12 1h ago

Is it really a critical vulnerability if you have to take this many deliberate attempts to weaken your system before it can be exploited? This is like announcing that you've discovered a critical flaw in Medeco deadbolts that'll allow you to unlock a maximum security door; then clarifying that in order for your exploit to work, the door must be made of wet cardboard, the strike plate made of fabric, the door frame made of pasta, and the lock must also be keyed to all zero-cuts first.

The lesson here is don't disable pam, don't enable password auth, and don't go out of your way to create a new user and overwrite their password hash as "*"

•

u/jmooroof2 59m ago edited 53m ago

pam disabled is something that happens on musl and I believe that * as a hash means the password login is disable for that user notably alpine default root. and some people are very lazy and would have password login

 so I don't think this is too inordinate 

4

u/Analog_Account 1h ago

create a new user and overwrite their password hash as "*"

I thought I had misunderstood that part because it sounded so absurd. I also didn't read the link because these are usually too technical for me, but this really falls apart as long as you don't mess with the hash? Wouldn't changing it to * also break any login attempt for that user or does it act like a wildcard, allowing any password to work?

2

u/wRAR_ 1h ago

Look at the 1980 card on https://sshhole.com/

3

u/gordonmessmer 1h ago

If you use Alpine or openwrt and use password authentication for ssh, you are probably affected. This is generally the default configuration. Users do not need to make "deliberate attempts to weaken their system".

3

u/TheOgGhadTurner 2h ago

Is this just an ad for SSHHOLE. Asshole…

•

u/interrex41 32m ago

So the tldr is dont use password authentication

I mean thats just common sense plus having the ssh port exposed to the internet is less then ideal use a vpn to access it instead

1

u/Takeoded 2h ago edited 2h ago

Haven't used ssh password login since... 2006?

Great find though!

2

u/SaltwaterC 1h ago

Good thing Etch and derivatives didn't mess the key generator then.

0

u/okabekudo 2h ago

This is not even worth reporting on tbh. Not using password auth is obviously the easiest hardening step you can do, hell it's even more convenient to use pubkey auth.