Cloud security of a whole new sort! Airbus issues plane patch for “cosmic ray” vulnerability
Is this the funkiest CVE ever?
OpenSSH is the most widely-used remote access tool in the world, almost certainly by a huge margin.
It’s part of the security-conscious OpenBSD operating system, is a core package in most Linux distros, is part of Windows and macOS, and is used by many if not most hardware appliances out there, from the biggest and most expensive corporate firewalls to the basic home routers shipped out by ISPs.
Well, the OpenSSH team just very kindly published an emergency update (OpenSSH 10.6p2)․․․
․․․for a password bypass bug that’s not OpenSSH’s fault, but that’s caused by what can only be described as a comedy of errors in the low-level system library code that ships with some, but fortunately far from all, Linux distros.
Any Linux distro that’s based on the musl runtime library (most Linuxes use a much larger library known as glibc), or any build of OpenSSH that was hand-compiled to include the musl library itself instead of relying on the distro’s choice, is at risk.
In an almost-amusing irony, a non-standard hack used by the musl code to improve login security has collided with a long-used Linux sysadmin hack used to improve login security.
Although only a few Linux distros use the compact musl library instead of the traditional glibc, a notable one that does is Alpine Linux, a stripped-down distro that favors simplicity and small size over complexity and bloat, and that is therefore very widely used in virtual machines, containers, and cloud-based services – precisely because it’s compact.
These days, most Linux systems rely on a complex but powerful subsystem called PAM (short for pluggable authentication module) to manage passwords, passkeys, and other details of both local and remote logins.
Most Linux installations of OpenSSH are configured to use PAM, if the operating system provides it, and any system that does so isn’t at risk from this bug.
You can check if OpenSSH is using PAM for authentication with the command sshd -T | grep -i usepam. If the output is UsePAM yes, this bug won’t be triggered. No output, or UsePAM no, means you could be at risk.
But PAM is notoriously complex, and a stripped-down Alpine system typically handles password-based and other authentication itself, via the aforementioned musl runtime library.
Also, most Alpines use the system file /etc/shadow as a password database, which typically looks something like this:
Above, the account names followed by an exclamation point (!) are “password locked,” because the field in each line where those exclamations appear is supposed to be a password hash that’s used to validate the password supplied at login time.
The character “!” isn’t valid in any Linux password hash format, so inserting a “!” in front of a user’s password hash (or using “!” alone instead of a hash) prevents password logins on that account.
You can see what a valid hash looks like on the line for the account duck (you are welcome to crack this if you like – I’ve already forgotten the text I used, but it was a short string along the lines of notvalid).
And you can see a variation on the “!” theme for the passwordless account, where there’s a “*” instead, which works in a similar way to an exclamation point, because it too can’t appear in any valid password hash.
The “*”, however, is often used to denote that an account isn’t strictly locked out, but that it’s intended to be used with passwordless logins only, such as those using OpenSSH’s publickey authentication system, where a public-private keypair is used instead of a password.
Public-key SSH logins are very common – much more widely-used these days than password-based logins – because they’re ideal for automating logins by scripts, software development and content management tools, and AI agents.
And if an account isn’t meant to be accessible via password, why not use a marker in the password database that not only flags the account as passwordless but also prevents any password from working?
The comedy of errors here is that the musl password verification function (called crypt() if you would like to look it up) has a non-standard “feature” that seems to have been added to stop remote attackers wasting time by trying super-long passwords, even though they know they’re invalid.
A long password takes very slightly longer to hash than a short one, so an extra-super-long password, though it will never get you in, could cause what’s known as a denial-of-service (DoS) problem.
So, if musl detects that you’ve supplied a password of more than 256 characters, it reports an error instead of returning the hash.
There’s no standard way to report this sort of error, so musl does it (and you can guess where this is going) by returning an invalid, one-byte “hash”․․․
․․․consisting of the character “*“.
In other words, the special “this cannot match any real hash” character that musl uses to denote an invalid password just happens to match the special “this cannot match any real hash” character commonly used in the /etc/shadow database to denote that no password can ever be valid!
For reasons I shan’t explain here (but they are detailed splendidly in Alpine’s own advisory), this behavior only happens if at least one other account in the database does have a password set.
So, the long and short of if is that you are almost certainly in trouble if these conditions apply:
If that’s true, then an attacker who connects remotely to your SSH server and attempts to login can bypass authentication by simply:
Like this:
The OpenSSH team implemented a workaround that automatically rejects the fake password hash of “*” that comes back from musl’s crypt(). (Any “hash” shorter than 4 bytes is now considered bogus and won’t be used.)
Also consider turning password authentication off in OpenSSH if you known you have set up your accounts to use public-key authentication only.
Alpine notes that its tiny-cloud images were vulnerable by default, and that recent Alpine base images are set up with a root account tagged with a hash of “*”, so that although you’re safe to start with because root logins via SSH are blocked by default, you’re closer to trouble than you’d like.
Well done to OpenSSH for dealing with the problem even though the team writes, “We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.”
And well done to Alpine Linux for writing a thorough advisory and publishing fixes right away.
Ask how SolCyber can help you do cybersecurity in the most human-friendly way. Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit you or your business!
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Is this the funkiest CVE ever?
We know what you’re thinking. Should the word “beachhead” be “breachhead”?
The cybersecurity vendor market is quite complicated and it’s easy to get lost in the acronym soup. Whether it’s to make their product sound different or just the proclivity of the tech industry to abbreviate everything, it can be incredibly challenging for non-security people to understand what’s important and what isn’t. Making matters worse, many of the services overlap, meaning that you can invest in two “different” services or platforms and end up getting the same thing in both. One […]
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
