Hacker News

points by tonnydourado 2 days ago | 0 comments

Am I missing something or is this written up to seem a lot worse than it actually is?

It starts with a bold claim: "ssh accounts that should not accept a password will accept any password between 256 and 1024 characters". But then it keeps adding qualifiers:

- sshd compiled with musl

- not using PAM

- password logins enabled

- at least one account with '*' as the password "hash"

- at least one OTHER account with a valid password

- server is aligned with 2 ley lines

- hacker is wearing a blue t-shirt and green socks

Ok, the last two are an exaggeration, but still. The conditions are all ANDed, miss a single one and you're fine.

On top of that, as someone else in these comments reminded, the target account needs to have a valid login shell or other exploitable program assigned to it, and these passwordless accounts tend to have nologin or something similar.

To me this seems to fall on the "technically possible, practically very unlikely" bucket, kinda like the PHP vulnerability from the other day. Maybe this has gone unnoticed for so long because it just doesn't happen.

[–] pizlonator 2 days ago

There are a lot of systems that meet those requirements.

> - sshd compiled with musl

So alpine as well as a bunch of other embedded Linuxes. Huge install base.

> - not using PAM

What you get if you try to have a minimal setup. Default sshd config if you install from source.

> - password logins enabled

The default. Super common.

> - at least one account with '*' as the password "hash"

Almost every Linux system.

> - at least one OTHER account with a valid password

Almost every Linux system.

So sure, there are caveats, but they cover a massive install base.

This is a super bad bug

[–] tonnydourado 2 days ago

How many alpine installs are running sshd? Most containers using it as a base image aren't. Embedded Linux is unlikely to be running it, too. And if one IS running sshd, how often is it with unchanged defaults? I don't buy the inference here.

I'll concede that embedded linux might be my blindspot here. Maybe cheap web hosting, too, but that seems much less likely to be using musl.

[–] svnt 2 days ago

Embedded linux is your blindspot here.

[–] __MatrixMan__ 2 days ago

Rumor has it that Cisco has been hurriedly patching something and refusing to tell their customers what it is. I'm thinking it's this.

[–] tchebb 2 days ago

Most embedded systems I've seen use glibc or uClibc. I agree it would make sense for them to use musl, but the embedded space moves very slowly.

[–] pizlonator 2 days ago

Yes

[–] andix 2 days ago

A lot of embedded systems use musl and no PAM. Some of them might use Alpine, but the distribution doesn't matter that much.

[–] 3m4r 2 days ago

Most of those would be using dropbear rather than openssh.

[–] tonnydourado 2 days ago

And ssh? I'd assume most would use proprietary or industry-specific standard for data IO, or just https, for domestic IoT stuff

[–] andix 2 days ago

And also ssh in many cases.

[–] pera 2 days ago

I thought Dropbear was pretty much the defacto SSH server for embedded applications, is OpenSSH+musl actually a common combination for these scenarios?

[–] 0x457 2 days ago

Well, OpenWrt is OpenSSH + musl.

[–] andix 1 day ago

Some use Dropbear, some use openssh.

This vulnerability clearly is not one that affects everyone like the PHP vulnerability did. But it's exposure is still significant and very easy to exploit. As easy as it gets.

[–] lucideer 2 days ago

> Most containers using it as a base image aren't.

On top of the embedded linux blindspot, this statement seems unfounded.

> if one IS running sshd, how often is it with unchanged defaults?

By definition, I would imagine the answer to this is most of the time.

[–] qwm 2 days ago

For what it's worth, default Alpine installs don't have an account with * as its password hash if you use the root account as your main one. Not sure if that's also true for ones where you set up a user, maybe those ones are vulnerable.

[–] utopiah 2 days ago

I'm genuinely curious what's the Venn diagram here because I feel a lot of embedded systems precisely have one condition but not the other, e.g. password yes but not necessarily multiple accounts, e.g root only, while using musl. Namely almost all for almost all, but if only one is not overlapping another then it's actually very few.

[–] yjftsjthsd-h 2 days ago

>> - at least one account with '*' as the password "hash"

> Almost every Linux system.

But not, notably, on Alpine, which uses '!' instead.

Edit: or maybe yes on Alpine? I checked my desktop and it has zero *s in shadow, but Alpine's post seems to say they do use * sometimes

[–] tremon 2 days ago

I thought they had a difference in meaning, i.e. * means the user has no password and ! means that password logins are disabled for this user, but the man page does not make it clear if there's a distinction.

From man 5 shadow:

> A password field which starts with an exclamation mark means that the password is locked.

> If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).

[–] LinaLauneBaer 2 days ago

does this really matter? It could be used to do something devastating. The number of systems that match those requirements is only one factor. If just a handful of those are highly critical for humanity it could lead to disaster. Eg. hacks into fridges, centrifuges etc.

[–] rhet0rica 2 days ago

Updates since this was posted:

- blue t-shirts and green socks have been added to the default loadout for new hackers, since it's optimal according to AI and costs nothing to the attacker in terms of compute

- there are so many ley line "maps" out there that basically any server placement counts as aligned with at least two, so this one's free also

[–] Onavo 2 days ago

Blue t shirts and green socks?

[–] petecooper 2 days ago

Vulnerability-branded merch? Unsure.

[–] b112 2 days ago

Someone owns a blue shirt/green socks clearance warehouse, this is all just and ad? I've seen weirder. I can imagine visiting SanFran in a few months, and it looks like a weird sci-fi movie scene, everyone dressed the same.

[–] dcrazy 2 days ago

SF has puffer jackets. Milan has men in blue suits. Paris has women whose wardrobes consist of black and white.

[–] alexchamberlain 2 days ago

> password logins enabled

Disabling sshd password logins is security 101, and the default for some cloud provided images these days. If password logins haven't been disabled, what other doors have been left open anyway?

[–] twothreeone 2 days ago

Now the question for the man: would fil-c prevent it :D

[–] vadansky 2 days ago

> > - password logins enabled

> The default. Super common.

This always seems bonkers to me. I think SSHD should give you ONE password free connection of setup to copy your key over and then it just shuts the door behind it.

[–] hnfong 2 days ago

I think it has to be a time limited FREE offer. (like, seriously, what if the user doesn't take the offer?)

It might actually a good idea, but I would likely avoid it since my built-in Bayesian filter would just mark it as spam.

[–] diath 2 days ago

Not sure why you're getting downvoted as from security standpoint that would be the right thing to do; but actual good server providers take it up a notch and allow you to upload the public key through their admin panel during server set up and the password you get only works locally for sudo etc. There's no reason why a fresh Linux setup should ever offer a publicly available SSH server with password based auth out of the box.

[–] hnfong 2 days ago

Alpine Linux (which uses musl) images are popularly deployed by those who use docker, and apparently the issue is there on the default install.

Not sure whether the PHP vulnerability actually had been exploited, but I'm pretty sure there are literally thousands of machines out there affected by this ssh issue right now as we speak.

This isn't going to end well.

---

Addendum (which may or may not be related to the above) --

Everyone has heard of the tale of the boy who cried wolf. The main moral of the story is not to troll your fellow townsfolks so they don't distrust you. But everyone with a sane mind gets that.

The (IMHO) under-appreciated lesson is actually: don't be those villagers. Believe stories you are given, even if you might look like a fool for believing in them. Don't assume what happens is the same as what happened in the past. Look at the facts yourself. Trust and verify.

[–] VorpalWay 2 days ago

You don't typically run sshd in containers, instead you only run whatever single service you set up your container for.

Sure there are native Alpine installs too, but that is far less common of a use case.

[–] tonnydourado 2 days ago

Who's out there running sshd inside a docker container? It's almost MORE work than exec-ing into the container.

[–] hylaride 2 days ago

I've done it in the past with "serverless" sftp servers, which is how a lot of inter-company batch transfers happen for historical reasons, especially in the financial sector. I don't recall what images I used, but it was far easier to patch with a CI/CD pipeline. We did use keys, though.

[–] cluckindan 2 days ago

Probably a lot of companies which have their own k8s cluster and segregate kubectl access to operations only. Developers still need a way to their app backend in some cases.

[–] chuckadams 2 days ago

Kubernetes already comes with better solutions for that sort of thing. I could see a ssh bastion container for bridging to legacy infrastructure though. Manage its keys right and it's probably more secure than a lot of alternatives.

[–] jbvlkt 2 days ago

Even if you do that why would you allow it outside VPN?

[–] cluckindan 1 day ago

You wouldn’t, but it would still remain an avenue for lateral movement

[–] zbentley 2 days ago

Several CICD solutions which offer "shell into container to debug a build failure".

You'd think they'd all do the smart thing and exec a shell into the container's namespace. You'd be wrong.

[–] Jolter 2 days ago

I have done that in the past, in order to be able to automate copying files to the container during testing or data migration. It was an ugly hack and now I need to make double sure none of those containers are still running…

[–] Brian_K_White 2 days ago

Everyone who has access to their container and not the host except by some terrible vnc or web console.

[–] andix 2 days ago

Alpine in containers is usually not affected. Most images/containers haven't ssh/sshd installed at all. Remote access is usually done from the host system.

[–] 63stack 2 days ago

You could start with trust and verifying what you wrote first, the popular usage of alpine in docker containers don't run sshd.

[–] hnfong 2 days ago

Even if 0.1% of those machines run sshd I guesstimate we'd still be talking thousands.

[–] tcdent 2 days ago

Really, "password auth enabled" should be enough to be a non starter these days.

[–] qwm 2 days ago

you'd be surprised

[–] itemize123 2 days ago

only 1) is a narrowing filter. the rest is basically the majority.

[–] VorpalWay 2 days ago

Most linux distros use PAM, so 2 is also a narrowing filter. Debian, Ubuntu, Fedora, Arch, etc all use PAM.

[–] jack1142 2 days ago

What if you narrow it down to musl-based distros (which none of the above are). Do most musl-based distros use PAM?

[–] VorpalWay 2 days ago

Alpine is mostly used in containers, where you don't run sshd anyway. It apparently doesn't use PAM by default though.

OpenWRT also doesn't use PAM by default apparently, and there is a risk of people using password login, which you should never do past initial setup.

But outside specific niches, musl is rare, with good reason. Performance is a joke compared to glibc, especially the allocator. The only reason to choose musl in my opinion is for memory constrained devices (OpenWRT etc) or for building static binaries where performance doesn't matter but portability does. I consider the "small container" use case questionable: performance will suffer, and you could share large base layers instead which would amortize the cost over many different images.

[–] kasabali 2 days ago

AFAIK OpenWRT doesn't use openssh

[–] jack1142 2 days ago

Yeah, OpenWRT doesn't use openssh by default - it uses dropbear. You can install openssh, if you want more features and there seem to be 2 packages - one with PAM support (openssh-server-pam) and one without it (openssh-server). PAM-less one is the one without the suffix so perhaps it's more likely you'd install that one out of the two, but only if you were trying to switch to using openssh in the first place.

[–] anamexis 2 days ago

Those distros are all filtered by 1, no?

[–] j45 2 days ago

I think you're missing the reason why it's relevant now.

LLMs will find it.

They work endlessly at finding the 'and' scenarios.

This should have been closed up a long time ago.

[–] edf13 2 days ago

Yes - immediately had me in a mild panic that I’d missed another AI discovered crit bug!

Had to quickly scan the rest of the homepage of HN to confirm.

[–] alienbaby 2 days ago

I suppose there is the chance you get to prep a system setup at one time, so you can access it at a later time?

[–] ShinyLeftPad 2 days ago

Yes, 100% written to oversell it as hard as possible. Still a vuln but karma farming too.

[–] CodeWriter23 2 days ago

Yes, missing the rest of the world that does not conform to your self-references.

[–] arunc 2 days ago

> - hacker is wearing a blue t-shirt and green socks

You had me there :D

[–] cubefox 2 days ago

> kinda like the PHP vulnerability from the other day

What? Pretty sure Cloudflare detected widespread attacks almost immediately after it was published. We are probably lucky that not much more happened because of responsible disclosure and the large media attention led to widespread admin awareness.

[–] bigbuppo 2 days ago

Every time I see one of these named exploit sites I always think, "Hey look at this guy, he wants attention."

[–] huslage 2 days ago

It’s irrelevant how widespread it is. It’s a bad bug that should be fixed. Why do people always say stuff like this? If you’re running a system that is exploitable then you deserve to know about it and to be provided a fix. It doesn’t matter all that much how widespread it is. The CVE system doesn’t exist to cater only to highly exposed systems.

[–] its_ethan 2 days ago

It matters how widespread it is because humans have limited time and resources to solve problems. If these conditions only exist in 0.001% of installs, is it worth the man hours to fix it? Alpine may think not, because like others have mentioned, there are likely other higher probability vulnerabilities being exposed in order to meet the conditions for this to even matter. A judgement call can (and clearly has?) be made to prioritize other work.

The good news is that considering Alpine is open-source, you can be the one to make the judgement call that it is worth fixing and go out there and fix it ;)

[–] tchebb 2 days ago

A trivial-to-exploit auth bypass is always worth fixing, no matter how few systems are affected right now in practice. My question is whether it's worth giving the vulnerability a name and making a webpage for it.

[–] its_ethan 2 days ago

Sounds like you should go fix it then!

[–] gf000 2 days ago

0.001% of all Linux installs (including containers, CI workers, embedded, etc) is still a huge huge number. It should be taken seriously until proven otherwise

[–] its_ethan 2 days ago

ok then, you should go fix it! and thanks for pretending the entirely made up number of 0.001% actually matters