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

821–830 of 1001 posts

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

#821

Post by tootie »

formerly_proven wrote: post #132
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…

I think this has been in the making for almost a year. The whole ifunc infrastructure was added in June 2023 by Hans Jansen and Jia Tan. The initial patch is "authored by" Lasse Collin in the git metadata, but the code actually came from Hans Jansen: https://github.com/tukaani-project/xz/commit/ee44863ae88e377... > Thanks to Hans Jansen for the original patch. https://github.com/tukaani-project/xz/pull/53 There were…

Does anybody know anything about Jia Tan? Is it likely just a made up persona? Or is this a well-known person.

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

#822

Post by aardvark179 »

ikekkdcjkfke wrote: post #619
jaredallard2 wrote: post #545

Earlier quoted context omitted.

Hey all, I’m the author of that PR. Just posted to Github with additional context: https://github.com/jamespfennell/xz/pull/2#issuecomment-2027...

The dopamine hits from updating stuff should come to an end, it should be thought of as adding potentially new bugs or exploits, unless the update fixes a CVE. Also Github needs to remove the green colors and checkmarks in PR's to prevent these dopamine traps from overriding any critical thinking

I strongly disagree. If you don’t update your dependencies then it’s easy to lose the institutional knowledge of how to update them, and who actually owns that obscure area of your code base that depends on them. Then you get a real CVE and have to work out everything in a hurry.

If you have a large code base and organisation then keep doing those upgrades so it won’t be a problem when it really matters. If it’s painful, or touches too many areas of the code you’ll be forced to refactor things so that ceases to be a problem, and you might even manage to contain things so well that you can swap implementations relatively easily when needed.

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

#823

Post by [deleted] »

sroussey wrote: post #426
0xthr0w4 wrote: post #339

Out of curiosity I looked at the list of followers of the account who committed the backdoor. Randomly picked https://github.com/Neustradamus and looked at all their contributions. Interestingly enough, they got Microsoft to upgrade ([0],[1]) `vcpkg` to liblzma 5.6.0 3 weeks ago. [0] https://github.com/microsoft/vcpkg/issues/37197 [1] https://github.com/microsoft/vcpkg/pull/37199

OMG: look at the other contributions. He is trying to take over projects and pushing some change to sha256 in a hundred projects. Example: https://github.com/duesee/imap-flow/issues/96

[deleted]

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

#824

Post by sroussey »

masklinn wrote: post #464
sroussey wrote: post #426

Earlier quoted context omitted.

OMG: look at the other contributions. He is trying to take over projects and pushing some change to sha256 in a hundred projects. Example: https://github.com/duesee/imap-flow/issues/96

This guy's interactions seem weird but it might just be because of the non-native english or a strange attitude, or he's very good at covering his track e.g. found a cpython issue where he got reprimanded for serially opening issues: https://github.com/python/cpython/issues/115195#issuecomment... But clicking around he seems to mostly be interacting with interest around these bits e.g. https://github.com/python/cpyth…

True, it does seem innocent enough upon more reflection.

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

#825

Post by NekkoDroid »

multimoon wrote: post #203

It seems like based on the (very well written) analysis that this is a way to bypass ssh auth, not something that phones out which would've been even scarier. My server runs arch w/ a LTS kernel (which sounds dumb on the surface, but was by far the easiest way to do ZFS on Linux that wasn't Ubuntu) and it seems that since I don't have SSH exposed to the outside internet for good reason, and my understanding is Arch n…

Being included via libsystemd isn't the only way ssh can load liblzma, it can come as an indirect dependency of Selinux (and its PAM stack) IIUC. Which makes it even a bit more funny (?) since Arch also doesn't officially support any Selinux stuff.

There might be other ways sshd might pull in lzma, but those are the 2 ways I saw commonly mentioned.

On a different note, pacman/makepkg got the ability to checksum source repository checkouts in 6.1.

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

#826

Post by WhyNotHugo »

pmarreck wrote: post #820
jnxx wrote: 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.

I have some questions. 1) Are there no legit code reviews from contributors like this? How did this get accepted into main repos while flying under the radar? When I do a code review, I try to understand the actual code I'm reviewing. Call me crazy I guess! 2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.

> 2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.

Any government which uses GNU/Linux in their infrastructure can pitch this as an attempt to backdoor their servers.

The real question is: will we ever even know who was behind this? If it was some mercenary hacker intending to resell the backdoor, maybe. But if it was someone working with an intelligence agency in US/China/Israel/Russia/etc, I doubt they'll ever be exposed.

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

#827

Post by fsckboy »

guinea-unicorn wrote: post #416
hangonhn wrote: post #255

Earlier quoted context omitted.

I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.

I find it funny how MFA is treated as if it would make account takeover suddenly impossible. It's just a bit more work, isn't it? And a big loss in convenience. I'd much rather see passwords entirely replaced by key-based authentication. That would improve security. Adding 2FA to my password is just patching a fundamentally broken system.

>I'd much rather see passwords entirely replaced by key-based authentication

I've never understood how key-based systems are considered better. I understand the encryption angle, nobody is compromising that. But now I have a key I need to personally shepherd? where do I keep it, and my backups, and what is the protection on those places? how many local copies, how many offsite? And I still need a password to access/use it, but with no recourse should I lose or forget. how am I supposed to remember that? It's all just kicking the same cans down the same roads.

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

#828

Post by logankeenan »

llmblockchain wrote: post #527
moritonal wrote: post #499

Earlier quoted context omitted.

Warning, drunk brain talking. But a LLM driven email based "collaborator" could play a very long gMw adding basic features to a code made whilst earning trust backed by a generated online presence. My money is on a resurgance in the Web of Trust.

State level actor? China?

You're likely being downvoted because the Github profile looking like east Asian isn't evidence of where the attacker/attackers are from.

Nation states will go to long lengths to disguise their identity. Using broken Russian English when they are not Russian, putting comments in the code of another language, and all sorts of other things to create misdirection.

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

#829

Post by dotty- »

_lvbh wrote: post #22
yogorenapan wrote: post #6

Very strange behavior from the upstream developers. Possible government involvement? I have a feeling LANG is checked to target servers from particular countries

One thing to note is that the person that added the commits only started contributing around late 2022 and appears to have a Chinese name. Might be required by law to plant the backdoor. That would be quite scary considering they have contributed to a wide variety of projects including C++ https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...

The contribution to C++ is just a simple markdown change: https://github.com/MicrosoftDocs/cpp-docs/pull/4716 C++ is fine.

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

#830

Post by WhyNotHugo »

mongol wrote: post #451
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…

Interesting that one of the commits commented on update of the test file that it was for better reproducibility for having been generated by a fixed random seed (although how goes unmentioned). For the future, random test data better be generated as part of the build, rather than being committed as opaque blobs...

I agree on principle, but sometimes programmatic generating test data is not so easy.

E.g.: I have a specific JPEG committed into a repository because it triggers a specific issue when reading its metadata. It's not just _random_ data, but specific bogus data.

But yeah, if the test blob is purely random, then you can just commit a seed and generate in during tests.

Post reply on HN