[Bug]: Upstream compromised? Or is the compromise? #92
Comments
This reverts commit 784e59f. 5.6.0 and later are compromised upstream and contain malware. https://lists.macports.org/pipermail/macports-dev/2024-March/045563.html https://lists.debian.org/debian-security-announce/2024/msg00057.html https://www.openwall.com/lists/oss-security/2024/03/29/4 tukaani-project/xz#92
|
Some more resources about this: Red Hat has published a security advisory about this: https://nvd.nist.gov/vuln/detail/CVE-2024-3094 Xe Iaso has an excellent blog post about this: https://xeiaso.net/notes/2024/xz-vuln/ Debian has released a security advisory about this: https://lists.debian.org/debian-security-announce/2024/msg00057.html Users of testing, unstable and experimental are advised to update. Users of stable distributions are unaffected. Ubuntu has not made an announcement, but I believe they are unaffected: the newest liblzma they ship is 5.4.1. |
|
Ubuntu published 5.6 in proposed for some time, then it looks like it was reverted: |
|
This comment on Hacker News suggests very heavily the OP is and was a bad actor for a long time. All things considered it definitely sounds like deep review of lots of things (linked binaries, kernel, containers, etc.) is going to be needed and simply rolling back one release might not be enough. |
|
I think having some kind of blog or text-response may be useful, because after reading: https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/ I am confused whether I am possibly affected. I assume no, because I do not use debian, |
The original files were generated with random local to my machine. To better reproduce these files in the future, a constant seed was used to recreate these files.
|
This comment on Hacker News has some loose ends of a paper trail pointing not just to @JiaT75 but also @hansjans162 as likely being involved (or possibly an alias of the same actor?). Lots more rabbit holes to go down to root out the mess... |
It depends on how exactly you downloaded the file. If you went onto the Releases page and downloaded the tarball, then you have the vulnerability. You can see this by opening one of the tar files, and opening m4/build-to-host, and looking at line 63, which is the same line that the openwall announcement says is part of the backdoor. On the other hand, if you went to the home page, and you clicked on a tag, then clicked "download zip," then you got the files that are in Git, which are different than the release tarball. You would not be affected by the vulnerability in that case. (Unless there is some other backdoor that we haven't found yet.) |
|
Following up on @nickodell, some of the exploit code has been checked into Git and around for much longer than the latest releases, but just stashed in an obfuscated and compressed file that (according to current preliminary analysis) wasn't getting activated until recently. The code to trigger the exploit code was only added in the release tarball and gated behind various conditions. That doesn't mean other malicious things didn't happen in the past and deeper analysis is still being worked on to see if other triggers might have been present. The presently known and understood trigger was only recently activated and added to the tarballs. |
I'd say, if you're a compression library, it makes a lot of sense to have binary files containing compressed data in the repo, as part of your test suite. Which is what happened here. |
They even added that file to the @nickodell maybe there is another backdoor. |
|
openSUSE has also made their announcement. |
Binary files containing compressed data make sense. 35KB binary files containing compressed data, that decompress to apparent nonsense and have no documentation on how they were created, do not make sense. |
|
I'd be happy to understand why @Larhzu didn't react yet. |
|
CVE-2024-3094 is the CVE for this (and that should link to the Github internal page for this, let's see) |
Well, it is a national holiday in Finland, and late on a Friday. Some chance they're just out drinking. |
I agree. I was mainly responding to @capicy's overly general statement of "binary files don't belong on git". |
|
Does anyone have any information concerning the threat actor such as his identity or country of origin? |
From the sound of it, seems like a fake identity. Unlikely even GitHub can easily find out. |
|
Arch Linux has also made an announcement. |
|
@ddvarpdd This being a severe backdoor doesn't excuse racism. |
https://security.archlinux.org/ASA-202403-1
Considering upstream version 5.6.1 was released three weeks ago, I must say I find that statement rather strange. e: Fixed at https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad , by using the Git release rather than Github. Good job with the embargo, that is a thorougly unsuspicious commit that nevertheless does fix the issue. |
|
@ddvarpdd it's worth looking into what a "false flag" is. |
|
I suspect @JiaT75 just wanted to stay alive.. I hope this is the case. |
|
https://archlinux.org/news/the-xz-package-has-been-backdoored/ they made a main website announcement. seems like arch cant be backdoored? i am a moron however |
|
The scope is probably quite limited, but as Homebrew has rolled the package back just in case; I would update Brew. Although systemd isn't there, glibc does exist on Brew and might be present. |
could you please elaborate on the scope? and what is the point of updating brew itself instead of removing/downgrading the package? the main question if it was possible to affect Mac Silicons via this "bug", as far as i understand it was some kind of shellcode triggering hence it must be only x86_x64 targeted, correct me if im wrong please |
|
Without adding fuel to the fire, this is a good reminder about discretion in trust, vigilance, and security practices in F{L,}OSS dev and packaging. Recall also ProFTPD, OpenBSD, PyPi, rest-client. In the future, it would be useful for researchers and laypeople to submit SHA256, etc. hashes of known good and known bad artifacts to make tracing simpler. Cheers peeps and best wishes for cleanup and recovery. xz is a core package to FLOSS. |
|
Sorry, I meant update brew in the sense of "update the package you have installed on brew" which will actually result in a downgrade. You can view their report here: I'm afraid I do not have the expertise to speculate on the answers to your questions, so I'm going with the option provided by Homebrew maintainers. They do not believe theirs was affected. |
|
@skull-squadron that is a developing story. Did you see https://github.com/cyclone-github/scripts/blob/main/xz_cve-2024-3094-detect.sh#L40 and the bash script at https://www.openwall.com/lists/oss-security/2024/03/29/4? |
|
The code checks for linux and x86-64 as architecture according to Andres Freund (see https://www.openwall.com/lists/oss-security/2024/03/29/4). Apple has a different architecture. |
|
@ShePastAway0 The backdoor which has been found is quite sophisticated and relies on a prebuilt object file shipped as part of test files with this repository. As far as I am aware this object file is built for x86_64 and no other payloads have been found at the time of writing. However, it is not inconceivable that other attack vectors have been introduced in the past year--it will take more time to fully audit the changes made in the past year, e.g. we might find something like the the suspicious libarchive PR. A conservative approach would be to revert back to the last release made by Lasse Collins himself. |
This comment was marked as abuse.
This comment was marked as abuse.
|
@Midek, hopefully you're knowledgeable in infosec and just joking, but if not, you may want to look up what a false flag is. There are a lot of malicious actors out there, and folks who are quick to point fingers are the easiest to manipulate. If someone were trying to hide their tracks, planting a few false flags like making sure they committed at a similar time window each time, would be too easy a step for them to not take. Especially someone smart and dedicated enough to do this. |
I have no clue what you are trying to say, but on the off chance that you are not in the world of software engineering, here is a screenshot of me making a git commit with UTC+8 (note on the top right, my local time is UTC+11)
|
It's interesting to note that the "Jigar Kumar" in this thread that is pressuring Lasse to find a replacement maintainer has the same e-mail format ( It's seeming increasingly likely that every step of this process was carefully orchestrated by multiple sockpuppet accounts controlled by the same actor. |
It appears github has suspended the accounts of both project maintainers, but this is only shown in their entries in the "following" lists of accounts who follow them, not their main profiles: |
Locked by who though? |
|
@alanc Interesting find. Hans' account is also suspended. Somebody at GH probably has access (and possibly soon a legal mandate) to look into PII on those accounts and correlate activity. |
Ah this UI is really horrible. Thanks for finding out. That being said, a mail on oss-security would be a good start. |
https://www.openwall.com/lists/oss-security/2024/03/29/4 Like this one? Am I misunderstanding what "oss-security" is? |
No. From Lasse. |
|
|
Debian is currently looking into downgrading it even further, before the first contribution from the known bad actor, which may be an older 5.2 release (later ones were also cut by them), then reapplying only the security fixes that came later on top manually, for now. |
|
Is it safe to keep discussions here where their maintainers have delete access to the whole thread? I worry they may drop the discussion or repo. |
This comment was marked as spam.
This comment was marked as spam.
|
I'm pretty sure the maintainers are both suspended and can't do anything. |
This comment was marked as spam.
This comment was marked as spam.
|
Also there is archive.org. |
Nice! The link below is maybe better to see the updated archives. |
|
I'm going to close this for now. There's a huge amount of comments and speculation and it's not really actionable in terms of technical items to work on other than the obvious. I may start a new issue with a checklist of what is to be done to decontaminate things. If you need information on the incident, please see https://tukaani.org/xz-backdoor/. |
and others
I understand why the author(s) of the analysis of the backdoor being distributed by this project decided not to notify upstream first since it looks like either the upstream is the compromise or at least are compromised themselves, so reporting here first would have done nothing except give the culprit time to wiggle. But the cat is out of the bag now and I see comments all over the place pinging the author. I think it's high time a bug report here notifies people following this tracker there is an issue. Also this serves as a request for a postmortem. Either this project has members that are bad actors or the members have themselves been deeply compromised. Most evidence seems to support the former. If there is evidence of the latter I suggest getting it out there post-haste.
The text was updated successfully, but these errors were encountered: