upvote
There are a lot of systems that meet those requirements.

> - sshd compiled with musl

So alpine as well as a bunch of other embedded Linuxes. Huge install base.

> - not using PAM

What you get if you try to have a minimal setup. Default sshd config if you install from source.

> - password logins enabled

The default. Super common.

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

Almost every Linux system.

> - at least one OTHER account with a valid password

Almost every Linux system.

So sure, there are caveats, but they cover a massive install base.

This is a super bad bug

reply
How many alpine installs are running sshd? Most containers using it as a base image aren't. Embedded Linux is unlikely to be running it, too. And if one IS running sshd, how often is it with unchanged defaults? I don't buy the inference here.

I'll concede that embedded linux might be my blindspot here. Maybe cheap web hosting, too, but that seems much less likely to be using musl.

reply
Embedded linux is your blindspot here.
reply
A lot of embedded systems use musl and no PAM. Some of them might use Alpine, but the distribution doesn't matter that much.
reply
Most of those would be using dropbear rather than openssh.
reply
And ssh? I'd assume most would use proprietary or industry-specific standard for data IO, or just https, for domestic IoT stuff
reply
And also ssh in many cases.
reply
I thought Dropbear was pretty much the defacto SSH server for embedded applications, is OpenSSH+musl actually a common combination for these scenarios?
reply
> > - password logins enabled

> The default. Super common.

This always seems bonkers to me. I think SSHD should give you ONE password free connection of setup to copy your key over and then it just shuts the door behind it.

reply
I think it has to be a time limited FREE offer. (like, seriously, what if the user doesn't take the offer?)

It might actually a good idea, but I would likely avoid it since my built-in Bayesian filter would just mark it as spam.

reply
Alpine Linux (which uses musl) images are popularly deployed by those who use docker, and apparently the issue is there on the default install.

Not sure whether the PHP vulnerability actually had been exploited, but I'm pretty sure there are literally thousands of machines out there affected by this ssh issue right now as we speak.

This isn't going to end well.

---

Addendum (which may or may not be related to the above) --

Everyone has heard of the tale of the boy who cried wolf. The main moral of the story is not to troll your fellow townsfolks so they don't distrust you. But everyone with a sane mind gets that.

The (IMHO) under-appreciated lesson is actually: don't be those villagers. Believe stories you are given, even if you might look like a fool for believing in them. Don't assume what happens is the same as what happened in the past. Look at the facts yourself. Trust and verify.

reply
You don't typically run sshd in containers, instead you only run whatever single service you set up your container for.

Sure there are native Alpine installs too, but that is far less common of a use case.

reply
Who's out there running sshd inside a docker container? It's almost MORE work than exec-ing into the container.
reply
Alpine in containers is usually not affected. Most images/containers haven't ssh/sshd installed at all. Remote access is usually done from the host system.
reply
only 1) is a narrowing filter. the rest is basically the majority.
reply
Most linux distros use PAM, so 2 is also a narrowing filter. Debian, Ubuntu, Fedora, Arch, etc all use PAM.
reply