are you affected?
- is your sshd running on musl? (alpine, openwrt, buildroot, yocto)
- is it not using pam? alpine’s openssh-server doesn’t by default, or maybe you set UsePAM no
- are password logins still on? they are by default
- is there an account with just * as its password? key-only users, ldap users, root on alpine
- and some other account with a real password?
- then that * account takes any password between 257 and 1024 characters
on alpine’s official aws and azure images that’s the default alpine user, and it has passwordless doas. so it’s root
on debian, ubuntu, fedora or anything else with glibc? going through pam? dropbear? openbsd? you’re fine
Jesus Christ. Why?! How?
Edit: I can’t figure out how to upload gifs to Lemmy… please imagine
castle-nathan.gifcastle-nathan.gif
I don’t know why, but I always assumed that image was from Firefly. It’s the same color shirt and everything!
There are a lot of references to Firefly in Castle. It’s quite entertaining.
Didn’t he dress up as a “space cowboy” in one episode?
Me too
I can’t figure out how to upload gifs to Lemmy…
This isn’t nearly as bad as I thought it was. Also the author is very reliant on AI to the point where they didn’t think about what if someone wipes the logs.
Any effected devices should be wiped and redeployed
did you get hacked? check.
$ grep “Accepted password” /var/log/messages
That’s a really bad check unless you have an external box receiving logs and you’re looking there, because the first thing that a sophisticated attacker is going to do if they get in as root is remove the signs of their presence.
I mean, not that it’s not severe, but which container images have ssh baked in? If you’re using good stripped down images, you’re fine here.
Not sure where the overlap is between"ssh is enabled" and “one of those OSes”. LXCs maybe?
SSH enabled and the SSH port of the container accessible and it’s set for password auth.
And there’s an account in the container that has a password set. That’s already a security problem on its own.
Maybe something like git forges and gist alternatives?
They use key based authentication
I wonder if Forgejo / Gitea instances are vulnerable
Good Point! I’ll check if my forgejo container has password auth enabled. :D It’s LAN only though.
Remember, password-auth off is the problematic setting.
No you’re wrong. Stop dramatizing and spreading false info. From your link:
Prerequisites: Are password logins still on?
You can’t trigger this if password auth is disabled.
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.
Linux phones? PostmarketOS is alpine-based. And a lot of people may ssh to their phone.
I used to run SFTPGO in a container as a NAS type service. Their default image is based on Debian, but they offer Alpine versions. Password authentication is enabled by default.
Even if there is ssh it probably is going to be dropbear and it is unlikely that password based authentication would be enabled
I’m no cybersecurity expert, but from what I’ve heard from those who are, this is the new normal as anyone who formerly had no chance due to being a “script kiddie” can now just prompt an AI* to eventually find a vulnerability.
* oversimplification redacted
You’d think that but so far I haven’t seen an actual PoC exploit for the PHP vulnerability that doesn’t require misconfiguring the server. And this is over a week after the patches were released.
The way it works is that finding vulnerabilities required a lot of technical understanding and mental effort. A software could have a glaring hole in it for years without anyone finding out simply due to nobody really looking. AI just gives you the ability to do rudimentary exploit analysis around the clock without having to spend your own time. This is a wake up call to anyone making software in sloppy fashion.
But it isn’t quite as easy as saying “AI hack into this service”, if the person doing the hacking is using the same model as the person who made the service, and that person already asked the AI to do that and fixed the resulting exploit prior to release.
Even projects that use AI in a limited fashion to code or even not at all, often use AI to at least do some red team stuff prior to release.
I don’t really foresee any way this doesn’t even out eventually.
I’ve been setting
UsePam = nofor decades because leaving it on meant that it’d still present a password login of keys failed. Is this still the case, was I wrong from the beginning, or is this somehow ok?The way I read it, it is fine if you do not allow password authentication in general?
I wouldn’t recommend deploying any ssh server without reviewing the config and believe sane defaults are sane.
I’m assuming this is only if you allow password authentication? If you’re only allowing certificate based auth you should be safe, right?
Correct, password authentication must be enabled on the SSH daemon side of things to be vulnerable. The user account being logged into, on the other hand, can’t have a password set. But overall, PW auth must be on. The website OP linked is exceedingly bad at explaining the actual problem, see Alpine’s announcement for better info.
https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
Yep
NO! Exactly the opposite, that is the problem. Key-only is a prerequisite for this.Edit: see also, the first thing that pops up under the link.I was wrong, see below.
The “are you affected?” section directly contradicts this. It outright states you must have password authentication enabled. Otherwise, SSH never gives you a chance to even attempt a password.
Bottom of the page says what to do and gives 2 options to mitigate:
# update. openssh 10.6p2 fixes it. $ apk upgrade openssh # can't update yet? turn password logins off. $ echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf $ rc-service sshd restartSo if you disable password auth and only allow key auth, then you are unaffected (safe).
The introis a bit confusing but it means that if you have password auth on - then even if your regular ssh login requires a key, you are not safe.
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.
Certificate or key based auth is unaffected
NO! Exactly the opposite, that is the problem. Key-only is a prerequisite for this.Edit: see also, the first thing that pops up under the link.I was wrong, see below.
I think there is some confusion and potential for misinformation here. SSH in key-only mode (common configuration) protects you from this problem, because it never accepts or even attempts any passwords at all, regardless of length. SSH in password-allowed mode with at least one user who might be a key-only USER by merit of having a password hash of “*” (not a valid password hash) is a prerequisite for this. That is a very different and very common thing, as most systems come with at least one key-only user by default. But gaining access to that user with an incorrect, invalid password still requires having passwords enabled at all.
To be clear: Password access enabled is a prerequisite, and by extension, password access disabled (key-only) prevents this.
The website you linked clearly defines that all of these conditions must be true for you to be vulnerable, and as far as I can tell, it is exactly correct:
is your sshd running on musl? (alpine, openwrt, buildroot, yocto)
is it not using pam? alpine’s openssh-server doesn’t by default, or maybe you set UsePAM no
are password logins still on? they are by default
is there an account with just * as its password? key-only users, ldap users, root on alpine
and some other account with a real password?then that * account takes any password between 257 and 1024 characters
The * account which they suggest potentially being “key only” is the prerequisite you are talking about, but having SSH itself key-only (which is best practice anyway) prevents the attack entirely.
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.
The linked article literally says you need password login enabled at the ssh level. The account however needs to not have a password set
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.
That website is atrocious. It’s the web design equivalent of shoving five kilograms of sugar and whipped cream in a cup of coffee.
Now, now. Starbucks is a very successful business.
Yes, it was a stroke of genius to label their mediocre confectionery as “coffee”, although it can lead to near fatalities when someone who’s only ever had Starbucks encounters real coffee for the first time.
Still, my point stands. That website is like 20% useful content, 40% flair, and 40% wasted space.
“Cyber” ppl love to do this. This is basically their resume I guess? They have to sensationalize absolutely everything they can (not that this isn’t an important bug, but this could have been a 1-2 page white paper imo (like many of them))
The container thing is extremely unlikely. However, having worked with developers before, I know there are people who are running those AWS and Azure images with internet-facing SSH password authentication. If they hadn’t already been hacked, they’ve all been hacked now. Somebody just had to check Shodan for hosts in those IP ranges running OpenSSH and try a few usernames.
OP I know you’re trying to do good, but please try to understand the vulnerability before spreading FUD
Yeah fair, sorry about that. The intro + where I originally learned this from made me overreact a bit, it seems.
Most containers don’t run ssh right?
If I’m running containers on Alpine, doesn’t that mean that they already don’t offer SSH (sshd)? The entire point of Alpine as a base is to not add stuff you don’t need.
Unless you are running openssh with password authentication on Musl you are not impacted by this
Everything behind a good firewall and proxy.
No public facing url should ever not be proxied.
Only ports you explicitly forward. Ever.
How is crashing on an unhandled path in a security context not better?!
