- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
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
You must log in or register to comment.
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.
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!
Didn’t he dress up as a “space cowboy” in one episode?
There are a lot of references to Firefly in Castle. It’s quite entertaining.
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
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
Yep, those new fangled slop-kitties. The worst part is that there brute force hacking is being subsidized by people 401ks.
The irony - of course - is that their 401k money goes right into hacking those same people’s 401ks.
… but at least we can brainrot an entire generation with glass fruit slices and put artists out of work?
Now if you’ll excuse me, I have to go convince someone that the TikTok deepfakes they’re watching aren’t real and that cops don’t really employ nanny-boo-boos to unsettle criminals during interrogations. No, I’m not joking.
It’s not quite as simple as that. The author in this case followed a pretty specific trail to find the bug.
Where AI helped was as the last step. They already knew what the bug would do and where to look, but actually looking through the source code for all the possible musl implementations out there would have taken a lot of time.
So they brute-forced it instead and asked AI to spin up actual running instances of all those implementations and simply tried the bug against each of them, rather than looking at all the code.
Fair enough, but the overall idea stands:
The bar has been significantly lowered for what it takes to hack.
That’s because it turns out there are tons of vulnerabilities out there introduced by very lazy and/or dumb code.
It isn’t that AI has lowered the bar for hacking, it’s that it’s showing us just how much bad code is out there. The bar was already on the ground, we just didn’t know it.
After all is said and done AI will actually end up raising the bar for security everywhere.
Unfortunately we have a lot of legacy crap to clean first.
You’re doing mental gymnastics to argue with me. Let’s try what I said worded differently in a way that hopefully helps you realize we agree:
It is now easier to hack.
Ah I agree it’s easier to hack. What I don’t agree with is the notion that it enables a class of people that couldn’t hack before. It’s easier to hack, yes, but for the same people who were hacking before.
Ignorant people trying to use ready-made tools for hacking isn’t a new thing, it goes back a while, there’s even a term for it (script kiddies).
anyone who formerly had no chance due to being a “script kiddie” can now just prompt an AI* to eventually find a vulnerability
- me, in a comment you already replied to
Yes, and that’s what I disagree with. Neither AI nor scripts will make a script kiddie into an actual hacker.
“AI makes hacking easy” is like saying “building houses is now easy because we have cranes”. Sure, but if you jump into a crane without knowing what you’re doing it’s not magically going to make a house appear.
it goes back a while
It goes back at least to my teen years, which is… not remotely recent. (Edit: 90’s for the record)
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?I’m not following. Are you saying you login with ssh keys and not the password, but leave “UsePam = no” so then if ssh fails you don’t have a pam error?
It’s been years since I was experimenting, trying to set things up properly, but at the time I could swear that I’d have the following set:
PubkeyAuthentication yes PasswordAuthentication no UsePam yesand attempts to SSH into the system would still result in a password prompt, even though
PasswordAuthenticationwas set tono. After some experimentation, I found that if I setUsePamtono, you wouldn’t get a password prompt, so that’s what I’ve been doing on every SSH server I’ve had since like, 2000.Tinkering with it now though, I see there’s also another directive,
KbdInteractiveAuthentication, which when set tono, will ensure I don’t see a password prompt even whenUsePamis set toyes. I can only assume that 26ish years ago there was noKbdInteractiveAuthentication, or I just didn’t know about / notice it!Well no harm done in my case anyway, as I don’t generally expose SSH servers to the outside world anyway. But it’s good to know that I don’t have to turn off PAM to disable password logins anymore.
The way I read it, it is fine if you do not allow password authentication in general?
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.
Linux phones? PostmarketOS is alpine-based. And a lot of people may ssh to their phone.
checked on my phone, there are a few system users with
!*as their password, from what i can tell!blocks all logins and is not bypassed by this exploit, but their shell is set to/sbin/nologinanyways.The default firewall rules of nura block ssh from mobile data, so only wifi and usb connections would be affected if at all.
Everyone should disable ssh password auth anyways, using the phones often short pin for ssh is not secure.
Most Android apps that make a ssh server use dropbear afaik.
Nura (formerly PostmarketOS) is not Android.
I expect it’s a common trend though, people generally use Dropbear on embedded devices for the same reasons they prefer Alpine, it’s more compact.
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.
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.
I use alpine with an ssh port exposed to the internet so I can connect to it. This doesn’t seem to be an issue if you configured your settings to be secure.
Never use just default settings.
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.
How is crashing on an unhandled path in a security context not better?!
I wouldn’t recommend deploying any ssh server without reviewing the config and believe sane defaults are sane.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters Git Popular version control system, primarily for code LXC Linux Containers NAS Network-Attached Storage SSH Secure Shell for remote terminal access
4 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.
[Thread #159 for this comm, first seen 5th Nov 2026, 15:30] [FAQ] [Full list] [Contact] [Source code]
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/
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.
Why
can u read
I sure can, but also why?
Why would you have SSH on a container in the first place?
Yah I was trying to figure out why you would have ssh installed in a container that likely gives you console access through a hypervisor (i.e docker) and then have that ssh server exposed to the internet…hummm
Oh, forgive me; I did not see that this was the selfhosted community. I almost made the mistake of assuming anyone here might know how computers work! I will strive to do better moving forward, thank you for your patience.
