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
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.