OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability (hachyderm.io)

86 pointsby Animux3 hours ago31 comments

amluto an hour ago

Wow, what a bug. I expect the exploit is literally as simple as trying to ssh in as a user with the password has ‘*’ in /etc/shadow and typing anything as the password.

To the extent that systems that are configured in the vulnerable manner exist in the wild, I’m surprised they weren’t exploited years ago by trivial ssh bots.

P.S. Wow, I’m reminded of just how awful traditional UNIX-y C APIs and code are.

P.P.S. The musl code in question is nuts. The API it implements is awful. Seriously, here’s the manpage:

https://man.archlinux.org/man/crypt.3.en

You can’t call this function correctly. sshd’s “fix” is basically to assume that a too-short return is an error return instead of a success return.

PAM is also awful, but this is worse.

throwa356262 3 hours ago

musl only, the quick fix:

     PasswordAuthentication=no

Which is a good advice in general.

solyin an hour ago

How do you break back into your digital life? You wake up in a strange place. Something happened. Everything's gone. No wallet/keys/smartphone/tablet/laptop. How would you get back into your digital life given only a laptop with access to the Internet, unless something, somewhere is passwordauthenticate=yes.

INTPenis an hour ago

Yeah your vault has password authentication. Your password manager in other words. Your vault is where you store your private ssh keys, and or the passwords for the keys.

viraptor an hour ago

Remotely: An encrypted file with a seed / master passwords to all the other data, published under a public url you can remember, but not linked anywhere and not listed.

Locally: Same, but printed out, laminated, in a safe place with other documents.

denkmoon an hour ago

I walk to my pc and type ssh-keygen. If i can’t do that I’ve got bigger problems. “I must be able to recover remotely using a memorised credential” is a terrible requirement.

jareklupinski 42 minutes ago

> You wake up in a strange place. Something happened. Everything's gone. No wallet/keys/smartphone/tablet/laptop.

at this point the _last_ thing i care about is my email.

where am i? am i ok? how are my friends/loved ones?

once those are in place, it becomes clearer how to get back to "normal"

petesergeant 32 minutes ago

1Password subscription and the memorized key. 1Password is the only place my ssh private keys are stored.

uresolame 10 minutes ago

1PaSsWoRd... SuBsCripTIon... it's just unbelievable how pathetic today's average HN user is...

fn-mote 31 minutes ago

The somewhere for password authentication is a place you have physical access. Not ssh.

mr_mitm 18 minutes ago

I log in via console, either physical or virtual (the latter requires MFA though)

patadura 35 minutes ago

imo this is a good advice only if the devices that connect to the server have their home encrypted and ssh private key protected.

asdfsa32 an hour ago

Who does PasswordAuthentication=yes in this day and age anyway.

ectospheno an hour ago

People who use AuthenticationMethods "publickey,password"

You must present a key first after which you must enter a password.

rvz 34 minutes ago

Just do no password at all.

ectospheno 27 minutes ago

Putting the one in 1fa? No thanks.

walrus01 26 minutes ago

As this is apparently affecting openwrt, probably a fair number of openwrt users, if I had to guess

mhitza 15 minutes ago

If you run a cockpit service on your server you will need password authentication enabled, unfortunately.

krystalgamer 14 minutes ago

it's the default for most systems. I can't remember a time I had to not turn it off.

K0nserv 29 minutes ago

This looks terrible for musl, what a collection of terrible decisions on their part. I guess I'm staying away from it.

sheepscreek 17 minutes ago

To err is human. There’s no escaping it, I’m afraid.

entuno an hour ago

Seems slightly confusing that the OpenSSH release notes page says:

> This release contains a critical security workaround that affects Linux systems that use the musl libc and PAM disabled.

But that there's nothing about it on their security page.

Even if it's not technically a bug in their code, the fact that they've made a "critical" release to address it suggests that it should probably be listed on the security page as well. But maybe (hopefully) they just haven't updated the security page yet.

jmclnx 34 minutes ago

>We consider the root cause of this bug to be outside OpenSSH itself, but we're in a good position to deliver a mitigation quickly.

So not a ssh issue but an issue specific to Linux using "musl libc without PAM".

crest 2 hours ago

I'm sure some people running lightweight containers just had a heart attack.

smw an hour ago

I would imagine the vast majority of lightweight containers don't contain an ssh server?

phoronixrly 2 hours ago

I presume Dropbear, thus musl-based OpenWrt routers are also not affected? Not that Dropbear has been an example in that regard.

manwe150 2 hours ago

Since after you posted, various people in the thread have reported dropbear is not affected

mijoharas 26 minutes ago

There is this write-up/fancy page from the person who found the vulnerability[0] (HN discussion[1], how I found this thread).

At the bottom of that it says dropbear is unaffected.

> on debian, ubuntu, fedora or anything else with glibc? going through pam? dropbear? openbsd? you're fine

[0] https://sshhole.com/

[1] https://news.ycombinator.com/item?id=50378228

jordiburgos 2 hours ago

Workaround? Why not a fix?

ale42 2 hours ago

AFAIU because the bug is in musl and not in OpenSSH