Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

591–600 of 1001 posts

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#591
post #228

I am not embarrassed to say... is there anything in there that someone who runs a server with ssh needs to know? I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence. If I am keeping stuff up to date, is there anything at all to worry about?

You should probably not be running your own publicly-accessible ssh servers if this email is not sufficient to at least start figuring out what your next actions are. The email itself comes with an evaluation script to figure out if anything is currently vulnerable to specifically this discovery. For affected distributions, openssh servers may have been backdoored for at least the past month.

> You should probably not be running your own publicly-accessible ssh servers if this email is not sufficient to at least start figuring out what your next actions are.

That seems like a fairly unreasonable stance.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#592
post #477

Earlier quoted context omitted.

And, Joey Hess has counted at least 750 commits to xz from that handle. https://hachyderm.io/@joeyh/112180715824680521 This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.

Anyone have any level of confidence that for example EL7/8 would not be at risk even if more potential exploits at play?

I wouldn't count on it. RedHat packages contain lots of backported patches.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#593

> Red Hat assigned this issue CVE-2024-3094. Does that mean this affects RHEL and Fedora?

RHEL won't get this bug for 2 years =)

i knew there was an advantage to being 8-10 years out of date at all times...

and when they do port finally backport this bug in 2026, they will probably implement the systemd integration with openssl (pbthththt...) via 600 patch files in some nonstandard divergent manner that thwarts the payload anyhow. see? i knew they were super duper secure.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#594

The latest commit from the user who committed those patches is weirdly a simplification of the security reporting process, to not request as much detail: https://github.com/tukaani-project/xz/commit/af071ef7702debe... Not sure what to make of this.

That repository is now disabled. But here's a similar change to the .github repository of tukaani-project from @JiaT75 to the bug report template:

    + or create a private Security Advisory instead.
Under a commit titled "Wrap text on Issue template .yaml files."

[1] https://github.com/tukaani-project/.github/commit/44b766adc4...

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#595
This gist summarizes the current situation very well: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...

Definitely looking like they were most likely some sort of state actor. This is very well done and all in plain sight. It's reassuring that it was discovered but given a simple audit of the release build artifacts would have raised alarms, how prevalent is this behavior in other projects? Terrifying stuff.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#596
post #584

Earlier quoted context omitted.

because of it's "great new features" "great" for whom? I've seen enough of the industry to immediately feel suspicious when someone uses that sort of phrasing in an attempt to persuade me. It's no different from claiming a "better experience" or similar.

I made a library where version 2 is really really much faster than version 1. I'd want everyone to just move to version 2.

But then you are saying a specific great new feature, performance, and not just the claim and concept performance, but numbers.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#597

Everybody here In jumping into the pure malice bandwagon, I have a better hypothesis. Abandonment and inaction, the actual developers of these tools are elsewhere, oblivious to this drama, trying to make living because most of the time you are not compensated nor any corporation cares about making things sustainable at all. This is the default status of everything your fancy cloud depends on underneath. An attacker t…

funding model of OSS work is obviously a problem, but these problems are deeper than that. even a very well compensated OSS developer can get a knock on the door from a government agency (or anyone with a "$5 wrench")[1] and they might feel "compelled" to give up their maintainer creds.

[1]: https://xkcd.com/538/

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#599
post #98
post #38

The terrifying part is that this was primarily found because the backdoor was poorly made and causing performance problems. Makes you wonder what more competent actors can do.

So many malicious actors have been caught because they accidentally created a mild annoyance for someone that went on to bird-dog the problem.

Unrelated: as a dog/pointer lover i really like the term "to bird-dog the problem". Never heard of it (iam from germany though)

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#600
post #432

Earlier quoted context omitted.

Github accounts of both xz maintainers have been suspended.

Not true, the original author wasn't suspended: https://github.com/Larhzu https://github.com/JiaT75 was suspended for a moment, but isn't anymore?

GitHub’s UI has been getting notoriously bad for showing consistent and timely information lately, could be an issue stemming from that.
Post reply on HN