Sshole

In-band signaling strikes again. * should not have been used as special value, neither for "no password" in /etc/passwd nor "error while hashing the password" in crypt. I'm afraid we'll find many more of these abuses, specially in string manipulations. The null was ok, an exception (or equivalent) better, and Result<T> (or equivalent) best.

Above all, I’m a little sad that the musl developers decided to make a lot of “well it’s convenient” changes to core crypto functions — at least without the level of auditing that would have caught this! It’s tarnished their reputation in my eyes a little.

Did anyone get it to work? I tried on the official alpine docker image, enabled password login for root. The shadow entry has ! as password by default, this didn't work with a > 256 character password (i also did passwd -l which also does !). I manually changed it to * and it still didn't work.

Am I doing anything wrong here?

OpenSSH_10.3p1, OpenSSL 3.5.9 29 Sep 2026

PRETTY_NAME="Alpine Linux v3.24"

That's a well-made site, yet I feel nothing.

To be fair, I have less than zero sympathy for anyone who runs SSH on any platform without `PasswordAuthentication=no` in 2026.

Its not asking for trouble, it is there will be trouble, not if but when.

As for the people who say "well, I run SSH on port 942329053052". Well guess what, the bots make short work on that. We tried it at $work as an experiment, multiple bots found it in less than a couple of hours. That's why your SSH config must be hardened, preferably running on a hardened OS too.

For OpenWRT, AsusWRT etc, I believe they use dropbear ssh by default instead of OpenSSH, which apparently isn't affected?

What is out there that uses musl without PAM and hosts an OpenSSH SSHd with PasswordAuthentication?

As in: "Actually out there"

The hypothetical Alpine exists, yes, but what runs that like that?

Oh so you can't pile patches on patches without understanding the whole system.

Also, idiomatic Rust would have prevented _parts_ of this. Idiomatic C would have too, but apparently nobody is writing idiomatic C.

From the other thread’s source [1], it affects musl without PAM. You can set PasswordAuthentication=no or update to remediate.

[1] https://hachyderm.io/@damienmiller/117563026759098135

came for the name, stayed for the story

Wow. I wonder which of the common fuzzers would have found this a decade ago. If literally any password over 256 chars works, that means nobody has ever fuzzed openssh on musl linux

I avoided using alpine-based containers ever since finding out a lot of Linux server software is actually Linux + SystemD software. The union set API of both Linux and SystemD seems to be the default "Linux API" today.

The bugs and commits that "fix" them reveal somewhat of a shitshow for how musl is managed. All projects have bugs, but I can't help but question why the wheel was reinvented here. Many toes have been stubbed along the way.

Haha insane, great find and write up

That's kind of shocking. I guess the swarm of AI related vulnerability findings continues.

Not the worst site, but it's clearly a publicity machine from wakefield.co, whom I haven't heard of. Also, exploitation conditions are super narrow, albeit, any password is wild.

Wait so musl, famously a stickler for standards, just changed the behaviour of a POSIX function?

A+ name

Magic characters are awesome.

> except a lot of programs never check for NULL. they just compare whatever crypt() gives back with the stored field, hit the NULL, and crash

> so musl (the libc under alpine) goes ok fine, crypt() just won't return NULL anymore. if it fails, it returns a single character instead.

Considering it's been accepted that crashing if malloc returns a NULL is your fault, did musl really feel the need to accommodate bad implementations like this or is this just AI speculation?

The real name of this is sshole - the is the "star" of the show, after all.

Of all the named vulnerabilities, I appreciate the history lesson and screenshots of how it got there

I really like creativity in the name, the way website built and the content

"tl;dr" was a bit of a downgrade though, but that's fine

it's a nice way to promote the company behind it

I liked that this site explained the vulnerability in an easy-to-understand way.

One more reason to build your (own) Docker images on 'FROM scratch' (basically nothing).

Related discussion: [0]

[0] https://news.ycombinator.com/item?id=50377221

at this point my only reaction is "are you fucking kidding me"

Can we just have a site with the text and images without the awkward scrolling crap? Hijacking basic features is an instant click away from sites for me

Edit: It seems to work fine on mobile. I'm not sure why the scrolling behaviour was added on the desktop version of the site

Yet another clankered finding creating a clankered website with clankered explanations. To be fair, this one's a lot better than the other clankered equivalents, but I wonder whether these people even know enough about their bug to have their own write-up?

Also, what's with this damn trend of typing in lowercase only? Why is this a thing?

> oh did i say "i"? sorry. i had agent swarms. a lot of them. let's not get into it

Still a cool finding... it's just the communication is becoming a lot worse these days - I want to understand the findings please, not be impressed by your webpage! Biggest gripe in recent memory is https://github.com/xoreaxeaxeax/skitter-creek-bath-salts

This is a super duper annoying site for people who just want to know if their systems are vulnerable, after patching like a dozen critical vulnerabilities in other software over the last week and are almost at the breaking point of resigning.

Can we have a “don’t treat me like five/toddler” / “idgaf about the explanation” quick link to a section for adults who need to patch systems?

(And if your reaction is “just scroll down, stupid”, I’m happy to report that with the scroll jacking, I scroll not enough / past the critical sections nine out of ten times.)

Edit: You may want to read https://sshhole.com/#exposure.