OpenSSH has a vuln condition which allows logging in without a password. A thread.

https://www.openssh.org/releasenotes.html

It only impacts Linux distributions which ship with musl libc and PAM disabled. I think that is just Alpine Linux (all versions).

It doesn’t impact Debian, Ubuntu, SUSE, Redhat or CentOS. Nor OpenWrt.

This is the technical change to fix https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482

@GossiTheDog Got a CVE for that? I don't see it in the release notes

@nielsa there’s no CVE allocated as far as I know

This is the mitigation for Alpine Linux. It does fully break legit password authentication with SSH.

https://fosstodon.org/@alpinelinux/117563196640515820

@GossiTheDog Why is it breaking password authentication?

@BucciaBuccia because you turn password authentication off

@GossiTheDog if I understand the fix correctly (and OpenSSH's description of the underlying vulnerability), it seems that what is being done is to enforce minimum length of a password (or the presence of an inputted password?) via an assertion on the length of the hashed value of the input.

What's wild about this is that the vulnerability depends on the libc implementation, suggesting that the correctness in the prior pw check implementation was to some degree incidental.

@GossiTheDog Please, my friend, we want to buy a shelter for my family to protect us from the rain and cold. The price of a tent here is $700, so please give me money to buy this tent.https://chuffed.org/project/208485-give-waleeds-family-a-chance-to-live

@GossiTheDog Please, my friend, we want to buy a shelter for my family to protect us from the rain and cold. The price of a tent here is $700, so please give me money to buy this tent.https://chuffed.org/project/208485-give-waleeds-family-a-chance-to-live

@GossiTheDog @BucciaBuccia Please, my friend, we want to buy a shelter for my family to protect us from the rain and cold. The price of a tent here is $700, so please give me money to buy this tent.https://chuffed.org/project/208485-give-waleeds-family-a-chance-to-live

@GossiTheDog We are living here in gaza a harsh life, beyond what any human can bear,We go through days that words cannot describe filled with pain and suffering,Please, donate and help in any way you can.
Donate or sharehttps://chuffed.org/project/208485-give-waleeds-family-a-chance-to-live

@GossiTheDog Please, my friend, we want to buy a shelter for my family to protect us from the rain and cold. The price of a tent here is $700, so please give me money to buy this tent.https://chuffed.org/project/208485-give-waleeds-family-a-chance-to-live

@GossiTheDog Please, my friend, we want to buy a shelter for my family to protect us from the rain and cold. The price of a tent here is $700, so please give me money to buy this tent.https://chuffed.org/project/208485-give-waleeds-family-a-chance-to-live

@GossiTheDog I think OpenWRT could be affected: https://openwrt.org/packages/pkgdata/libc says the libc metapackage will usually install musl, sometimes glibc. The openssh-server package depends on the libc metapackage: https://openwrt.org/packages/pkgdata/openssh-server

So it probably depends on PAM being available and enabled for a device, of which I'm not sure.

@wouter PAM’s on by default with OpenWRT

People are already spraying the Internet for this - they’re targeting root and alpine as usernames, and very long passwords (which bypasses auth).

First payload seen in honeypot is.. drumroll.. a coin miner.

Somebody probably needs to assign a CVE btw.

@GossiTheDog
Same as it ever was.

@GossiTheDog CVE's are pointless for such vulnerability, as it's not by a proprietary software developer who will otherwise not fix it.

The correct course of action is to tell people about the vulnerability Alpine GNU/Linux has and to also suggest consider installing a real free GNU/Linux-libre distro, with a real libc.

@Suiseiseki no, it isn’t.

@GossiTheDog anyone know if Docker containers running Alpine would have sshd running and enabled if ssh/sshd is not mentioned in the Dockerfile at all?

@bamboombibbitybop @GossiTheDog They shouldn't, but I would check just to be safe.

@dalias @bamboombibbitybop @GossiTheDog even if they did, unless you play with the networking options or expose the port, it won't be reachable.

https://sshhole.com/

Brb off to brief the business about the new Asshole vuln

@GossiTheDog Alpine underpins an awful lot of Docker containers. Their official image reports thirty million downloads a week.

https://hub.docker.com/_/alpine

@mhoye @GossiTheDog docker containers don't usually publish port 22.

@GossiTheDog oh fuck, like the openwrt that is reskinned and installed on the vast majority of residential router/firewall hardware out of the box? 😬

*edit* no, because openwrt doesn’t actually use openssh

/me chuckles in opnsense

@WiteWulf @GossiTheDog OpenWRT usually uses dropbear, so which shouldn't have this vulnerability.

@WiteWulf first post notes it doesn’t apply to openwrt, just Alpine

@GossiTheDog could this be *cue-dramatic-music* ssh2shell?

@GossiTheDog Void doesn't ship openssh with PAM disabled

https://blahaj.social/@leah/117563168608460670

@classabbyamp @leah cheers, corrected

@huronbikes @GossiTheDog It's what the libc does if crypt() fails. It used to return null.. on musl libc it now returns '*' which happens to match the password field on a bunch of logins.

AFAIK gnu libc returns '*0' which is way less likely to be in a password field, so they're not affected.

Personally I don't see what was wrong with null.

@tony glibc crypt() returns NULL on failure, which is also what POSIX requires.

@huronbikes @GossiTheDog

@GossiTheDog

https://fosstodon.org/@alpinelinux/117564620055820457

@GossiTheDog honestly if i ever found a wide-affecting cvss ten, then i would absolutely call it something unprofessional like "asshole", purely because it'd be funny

@Rairii

@GossiTheDog @BucciaBuccia which honestly there's a case for never allowing it to begin with, depending on the exposure of the system

@silhouette @GossiTheDog @BucciaBuccia Yeah, having PasswordAuthentication enabled for a server is a really bad idea. But it has always defaulted to on. I hope this will get more ppl to turn it off, maybe even Alpine to change the default.

@dalias @silhouette @GossiTheDog @BucciaBuccia

On Raspberry Pi OS (at least with press-Shift-at-boot install), you get a '/etc/ssh/sshd_config.d/50-cloud-init.conf' file, with PasswordAuthentication set to yes.

So also check what's included from 'sshd_config'.

@GossiTheDog wow :/

@tildeMtilde @GossiTheDog

@amszmidt @huronbikes @GossiTheDog Not true, if libcrypt is compiled with ENABLE_FAILURE_TOKENS it will return "*0" or "*1" instead. This is the default unless you specify --disable-failure-tokens in the configuration.

@tony The switch your talking about is not from glibc but from some other unrelated library (libxcrypt?). And has never existed in glibc.

libcrypt is not part of glibc since a few years

@huronbikes @GossiTheDog

@amszmidt @tony @huronbikes @GossiTheDog but POSIX goes on its way to only define one failure on which it should fail (-ENOSYS)

Also, libxcrypt by default does not return NULL on failure at all.
Honestly it's ssh's fault for checking crypt() on a user where it knows doesn't have a password. It is relying on the check to fail instead of failing early. Sure, it was done this way to add delay so one couldn't probe users .. but what prevents you from running crypt and disregarding its return value, on users w/o passwords?

@amszmidt @tony @huronbikes @GossiTheDog no one uses crypt functions from glibc (which I've been told are deprecated), everyone uses libxcrypt.

@fun Ok, and my response was explicitly about glibc, which .. the thread was about.

@GossiTheDog @huronbikes @tony

@fun POSIX says no such thing, ENOSYS is a errno value, an implementation can set something else for other situations. In either case, crypt() returns NULL on failure, irrespective what errno might be.

What I was replying to was only about glibc (which doesn't even implement a libcrypt libraryy, and as you mention, screams that crypt() is deprecated, etc).

@tony put the blame on glibc, which has none to bear.

@GossiTheDog @huronbikes

@jernej__s @WiteWulf @GossiTheDog aiui it’s not an openssh issue it’s musl, just openssh have patched to block it. dropbear may well also present the same vector.

@rfc6919 @WiteWulf @GossiTheDog It's an interaction between OpenSSH, musl and specific configuration (PAM being disabled).

RE: https://en.osm.town/@thibaultmol/117560287847621104

@GossiTheDog

@GossiTheDog @malwareminigun oh you've got to be fucking kidding me

@SteveSyfuhs @GossiTheDog @malwareminigun and all the "we block bad sites" lists have started blocking sshhole.com, which is infuriating.

@GossiTheDog @wouter I believe it's also true OpenWRT has password auth over ssh disabled by default *and* uses dropbear by default too? So one would have had to deviate from the defaults in multiple specific ways to make OpenWRT vulnerable. Curious to see if any commercial routers have tripped into this...

@keithzg @wouter yep I’ve seen no OpenWRT boxes that are vuln