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

751–760 of 1001 posts

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

#751

Post by junon »

mook wrote: post #727
junon wrote: post #514

Earlier quoted context omitted.

GitHub has suspended @JiaT75's account. EDIT: Lasse Collin's account @Larhzu has also been suspended. EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page. -- EDIT: Just did a bit of poking. xz-embedded was touched by Jia as well and it appears to be used in the linux kernel. I did quick look and it doesn't appear Jia touched anything of interest in there. I also checked the…

FWIW, that's mingw-w64-xz (cross-compiled xz utils) in AUR, not ming-w64 (which would normally refer to the compiler toolchain itself).

Good catch, thanks :)

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

#753

Post by alufers »

Roark66 wrote: post #743

Sadly this is exactly one of the cases where open source is much more vulnerable to a state actor sponsored attack than proprietary software. (it is also easier to find such backdoors in OS software but that's BTW) Why? Well, consider this, to "contribute" to a proprietary project you need to get hired by a company, go through their he. Also they have to be hiring in the right team etc. Your operative has to be in a…

Is that true? Large companies producing software usually have bespoke infra, which barely anyone monitors. See: the Solarwinds hack. Similarly to the xz compromise they added the a Trojan to the binary artifacts by hijacking the build infrastructure. According to Wikipedia "around 18,000 government and private users downloaded compromised versions", it took almost a year for somebody to detect the trojan.

Thanks to the tiered updates of Linux distros, the backdoor was caught in testing releases, and not in stable versions. So only a very low percentage of people were impacted. Also the whole situation happened because distros used the tarball with a "closed source" generated script, instead of generating it themselves from the git repo. Again proving that it's easier to hide stuff in closed source software that nobody inspects.

Same with getting hired. Don't companies hire cheap contractors from Asia? There it would be easy to sneak in some crooked or even fake person to do some dirty work. Personally I was even emailed by a guy from China who asked me if I was willing to "borrow" him my identity so he could work in western companies, and he would share the money with me. Of course I didn't agree, but I'm not sure if everybody whose email he found on Github did.

https://en.wikipedia.org/wiki/2020_United_States_federal_gov...

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

#754

Post by afiodorov »

wood_spirit wrote: post #124

A lot of eyes will be dissecting this specific exploit, and investigating this specific account, but how can we find the same kind of attack in a general way if it’s being used in other projects and using other contributor names?

We should be able to produce a tar and a proof that tar was produced from a specific source code.

Quote from the article:

    That line is not in the upstream source of build-to-host, nor is build-to-host used by xz in git.
Zero Knowledge virtual machines, like cartesi.io, might help with this. Idea is to take the source, run a bunch of computational steps (compilation & archiving) and at the same time produce some kind of signature that certain steps were executed.

The verifiers can then easily check that the signature and indeed be convinced that the code was executed as it is claimed and source code wasn't tampered with.

The advantage of Zero-Knowledge technology in this case is that one doesn't need to repeat the computational steps themselves nor rely on a trusted party to do it for them (like automated build - that can also be compromised by the state actors). Just having the proof solves this trust problem mathematically: if you have the proof & the tar, you can quickly check source code that produced the tar wasn't modified.

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

#755

Post by im3w1l »

stephc_int13 wrote: post #472

I guess that rewriting liblzma in Rust would not have prevented this backdoor. But would have likely increased the confidence in its safety. Using the build system (and potentially the compiler) to insert malicious backdoors is far from a new idea, and I don't see why this example would the only case.

This hack exploited a fairly unique quirk in the linux C ecosystem / culture. That packages are built from "tarballs" that are not exact copies of the git HEAD as they also contain generated scripts with arbitrary code.

It would not have happened in any modern language. It probably wouldn't have even happened in a Vistual Studio C-project for windows either.

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

#756

Post by soraminazuki »

waynesonfire wrote: post #556
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.

750 commits... is xz able to send e-mails yet?

It's hardly surprising given that parsing is generally considered to be a tricky problem. Plus, it's a 15 years old project that's widely used. 750 commits is nothing to sneer about. No wonder the original maintainer got burned out.

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

#757

Post by ui2RjUen875bfFA »

mborch wrote: post #724
Rhea_Karty wrote: post #672

TLDR: Some people have been throwing around “China,” but it seems also quite possible that Jia is from somewhere in Eastern Europe pretending to be from China. In addition, Lasse Collin and Hans Jansen are from the same EET time zone. These are my notes on time stamps/zones. There are a few interesting bits that I haven't fully fleshed out. The following analysis was conducted on JiaT75’s ( https://github.com/JiaT75?…

This 2011 addition to the XZ Utils Wikipedia page is interesting because a) why is this relevant, b) who is Mike Kezner since he's not mentioned on the Tukaani project page ( https://tukaani.org/about.html ) under "Historical acknowledgments". https://en.wikipedia.org/w/index.php?title=XZ_Utils&diff=pre... Arch Linux played an important role in making this compression software trusted and depended upon. Perhaps not a…

> Arch Linux played an important role in making this compression software trusted and depended upon.

because of the way arch distributes packages? then what you think about freebsd?

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

#758

Post by slowmotiony »

dimgl wrote: post #559
jchoksi wrote: post #458

The two active maintainers seem to be: Lasse Collin and Jia Tan Searching DDG for "jiat0218" I came across a blog post which I found weird. Seems to be dated: 2006-05-03 Blog post: "Kuso拍賣．有靈氣的筷子 - 闕小豪" https://char.tw/blog/post/24397301 > Internet Archive link: https://web.archive.org/web/20240329182713/https://char.tw/b... > The contents of the page when translated seems to be about jiat0218 auctioning a pair of sp…

Crazy to think that the time horizon for these kinds of attacks span decades. This absolutely does not read like a coincidence. Chopsticks, little sister, "room to work hard", all sound like codewords.

Sounds to me like google translate gibberish

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

#759

Post by hulitu »

cjbprime wrote: post #354
ncr100 wrote: post #258

Earlier quoted context omitted.

Security Researchers : Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.

In this particular case, there is a strong reason to expect exploitation in the wild to already be occurring (because it's an intentional backdoor) and this would change the risk calculus around disclosure timelines. But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users…

> but to the users of the software to finish updating their systems to a new fixed release,

Is there "a new fixed release" ?

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

#760

Post by nwallin »

idoubtit wrote: post #115
bonyt wrote: post #48

For those panicking, here are some key things to look for, based on the writeup: - A very recent version of liblzma5 - 5.6.0 or 5.6.1. This was added in the last month or so. If you're not on a rolling release distro, your version is probably older. - A debian or RPM based distro of Linux on x86_64. In an apparent attempt to make reverse engineering harder, it does not seem to apply when built outside of deb or rpm p…

The article gives a link to a simple shell script that detects the signature of the compromised function. > Running OpenSSH sshd from systemd I think this is irrelevant. From the article: "Initially starting sshd outside of systemd did not show the slowdown, despite the backdoor briefly getting invoked." If I understand correctly the whole section, the behavior of OpenSSH may have differed when launched from systemd,…

> Maybe some distributions that don't use systemd strip the libxz code from the upstream OpenSSH release, but I wouldn't bet on it if a fix is available.

OpenSSH is developed by the OpenBSD project, and systemd is not compatible with OpenBSD. The upstream project has no systemd or liblzma code to strip. If your sshd binary links to liblzma, it's because the package maintainers for your distro have gone out of their way to add systemd's patch to your sshd binary.

> From the article: "Initially starting sshd outside of systemd did not show the slowdown, despite the backdoor briefly getting invoked." If I understand correctly the whole section, the behavior of OpenSSH may have differed when launched from systemd, but the backdoor was there in both cases.

From what I understand, the backdoor detects if it's in any of a handful of different debug environments. If it's in a debug environment or not launched by systemd, it won't hook itself up. ("nothing to see here folks...") But if sshd isn't linked to liblzma to begin with, none of the backdoor's code even exists in the processes' page maps.

I'm still downgrading to an unaffected version, of course, but it's nice to know I was never vulnerable just by typing 'ldd `which sshd`' and not seeing liblzma.so.

Post reply on HN