Jai Tan's commit history on his github profile suggests he took off for Christmas, new years, and spring break. I smell an American.
Backdoor in upstream xz/liblzma leading to SSH server compromise
301–310 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#302Given the recent ( not so recent ) attacks/"bugs" I feel there is a need to do more than the already hard task of investigating and detecting attacks but also to bring IRL consequences to these people. My understanding is that right now it's pretty much a name and shame of people who most of the time aren't even real "people" but hostile agents either working for governments or criminal groups ( or both ) Getting pun…
In the article it says CISA was notified - that sounds like it's going to be a federal investigation if nothing else. If I was this person, I wouldn't be in the USA (or any US friendly nation) ASAP.
We shouldn't rule out the probability that this account is from a U.S. agency as well.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#303Very 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…
1 week ago "Hans Jansen" user "hjansen" was created in debian and opened 8 PRs including the upgrade to 5.6.1 to xz-utils
From https://salsa.debian.org/users/hjansen/activity
Author: Hans Jansen
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!2 New upstream version 1.17" - March 17, 2024
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!1 Update to upstream 1.17" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!2 New upstream version 1.17.0" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!1 Update to upstream 1.17.0" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!6 Update upstream branch to 0.10.6" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!5 Update to upstream 0.10.6" - March 17, 2024
- [Debian / Xz Utils](https://salsa.debian.org/debian/xz-utils): opened merge request "!1 Update to upstream 5.6.1" - March 17, 2024
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#304NixOS/Pkgs 23.11 unaffected, unstable contains backdoored implementations (5.6.0, 5.6.1) but their OpenSSH sshd does not seem to link against systemd/liblzma, and the backdoor doesn't get configured in (only happens on .deb/.rpm systems).
That's one of the advantages of NixOS - viruses and mass hacks have lesser chance to function due to how different this OS is. Until it gets more popular, of course.
It's actually not an advantage. The reason why the exploit wasn't included is because the attacker specifically decided to only inject x86_64 Debian and RHEL to reduce the chances of this getting detected.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#305Another interesting data point: about 2 years ago there was a clear pressure campaign to name a new maintainer: https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.h...
At the time I thought it was just rude, but maybe this is when it all started.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#306Yikes! Do you have any info on the individual's background or possible motivations?
I would presume it's a state actor. Generally in the blackhat world, attackers have very precise targets. They want to attack this company or this group of individuals. But someone who backdoors such a core piece of open source infrastructure wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency who is interested in surveilling, well, everything. Or it co…
[flagged]
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#307Earlier quoted context omitted.
> Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it is in fact an upgrade. I'm surprised .deb doesn't have a better approach. RPM has epoch for this purpose http://novosial.org/rpm/epoch/index.html
Debian has epochs, but it's a bad idea to use them for this purpose. Two reasons: 1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository. So, the current best practice is the +really+ thing.
Thanks for the info, the filename thing sounds like a problem, one aspect of the epoch system doesn't work for the purpose then.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#308That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.
The use of "eval" stands out, or at least it should stand out – but there are two more instances of it in the same script, which presumably are not used maliciously. A while back there was a discussion[0] of an arbitrary code execution vulnerability in exiftool which was also the result of "eval". Avoiding casual use of this overpowered footgun might make it easier to spot malicious backdoors. Usually there is a bett…
eval in autoconf macros is nothing unusual.
In (pre-backdoor) xz 5.4.5:
$ grep -wl eval m4/*
m4/gettext.m4
m4/lib-link.m4
m4/lib-prefix.m4
m4/libtool.m4Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#309Now consider that your average Linux distribution pulls in tens of thousands of packages, each of which can be similarly compromised. Pretty scary to think about.
The terrible desktop software security model of weak/essentially non-existent security boundaries at run and compile time makes this all the more spicy.
Computer security for billions runs on the simultaneous goodwill of many thousand contributors. Optimistically said it's actually a giant compliment to the programming community.
And this is not even talking about hardware backdoors that are a million times worse and basically undetectable when done well. The myriad ways to betray user trust at any level of computation make me dizzy...
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#310Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
Probably a state actor. You can look far into the future when you’re working for the party.
And that long term perspective could be used constructively instead!