Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

Post reply on HN
Print view View original

241–250 of 1001 posts

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

#241

Post by treffer »

mort96 wrote: post #212
treffer wrote: post #99

Earlier quoted context omitted.

Ubuntu still ships 5.4.5 on 24.03 (atm). I did a quick diff of the source (.orig file from packages.ubuntu.com) and the content mostly matched the 5.4.5 github tag except for Changelog and some translation files. It does match the tarball content, though. So for 5.4.5 the tagged release and download on github differ. It does change format strings, e.g. +#: src/xz/args.c:735 +#, fuzzy +#| msgid "%s: With --format=raw,…

FYI, your formatting is broken. Hacker News doesn't support backtick code blocks, you have to indent code. Anyway, so... the xz project has been compromised for a long time, at least since 5.4.5. I see that this JiaT75 guy has been the primary guy in charge of at least the GitHub releases for years. Should we view all releases after he got involved as probably compromised?

Thank you, formatting fixed.

My TLDR is that I would regard all commits by JiaT75 as potentially compromised.

Given the ability to manipulate gitnhistory I am not sure if a simple time based revert is enough.

It would be great to compare old copies of the repo with the current state. There is no guarantee that the history wasn't tampered with.

Overall the only safe action would IMHO to establish a new upstream from an assumed good state, then fully audit it. At that point we should probably just abandon it and use zstd instead.

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

#242

Post by nine_k »

Luker88 wrote: post #157

@people who write github scanners for updates and security issues (dependabot and the like) Can we start including a blacklist of emails and names of contributors (with reasons/links to discussions)? I can't track them and I don't want them in my projects. Might not be very helpful as it is easy to create new identities, but I see no reason to make it easier for them. Also, I might approach differently someone with l…

You can write a rather simple GitHub action that would do that: look at a PR and reject / close it if you don't like it for some reason. AFAIK open-source projects have a free quota of actions.

OTOH sticking to the same email for more than one exploit might be not as wise for a malicious agent.

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

#244

Post by freedomben »

gopher_space wrote: post #152
eigenvalue wrote: post #129

Earlier quoted context omitted.

Every single commit this person ever did should immediately be rolled back in all projects.

It's weird and disturbing that this isn't the default perspective.

Well, it is much easier said than done. Philosophically I agree, but in the real world where you have later commits that might break and downstream projects, etc, it isn't very practical. It strikes me as in a similar vein to high school students and beauty pageant constestants calling for world peace. Really great goal, not super easy to implement.

I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.

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

#246

Post by smeehee »

rwmj wrote: post #42

Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo. He has been part of the xz proj…

Debian have reverted xz-utils (in unstable) to 5.4.5 – actual version string is “5.6.1+really5.4.5-1”. So presumably that version's safe; we shall see…

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

#247

Post by mardifoufs »

agwa wrote: post #8

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…

What? I don't get it? Isn't it on Debian if they modified the package to do something like this? Why would you blame systemd for maintainers doing something that upstream has never required or recommended?

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

#248

Post by jpalomaki »

AdmiralAsshat wrote: post #52

Yikes! Do you have any info on the individual's background or possible motivations?

Seems to be a perfect project to hijack. Not too much happening, widely used, long history, single maintainer who no longer has time to manage the project and wants to pass it over.

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

#250

Post by arp242 »

JanisErdmanis wrote: post #128
notyoutube wrote: post #97

Is the solution against such attacks in the future only to scrutinize more, or are there other reasonable options in terms of hardening?

The lesson here seems to not depend on tools written in languages that have complex, obscure build systems and no one is either able or interested to read. Using tools rewritten in Rust, Go or any other languege which resolves dependencies within project seems the only way to do hardening here.

You don't need a complex obscure build system for most C code. There's a lot of historical baggage here, but many projects (including xz, I suspect) can get away with a fairly straight-forward Makefile. Double so when using some GNU make extensions.
Post reply on HN