The xz package has been backdoored

[Chiitoo]

[modnaruved]

Some important points that I would like to draw your attention to. I am sorry for my English.

The backdoor was identified during the detection of performance drawdown, although and insignificant.
Then, as a result of the review, a suspicious code. Moreover, the fact itself and the detection technique, the circumstances, also represent a big interest.
It probably makes sense to pay attention to the frequency of updates and generally an anomalies.
Obviously even now, it would be useful to continue conduct a comprehensive analysis and draw conclusions along the way.

Ideally there should be: a test cycle (in an isolated environment, but simulating typical environments) and "updates buffering"
Nice to have: CI, performance monitoring and analysis, identification anomalies. Something else.

Of course, it would be useful to analyze changes on a regular basis. Particular attention to analysis archives/tarballs, in particular generated ones.

Wherever there are junctions in the chain of changes during code delivery, they should especially check.
It is possible that tarballs/archives should be checked in the most thorough manner, schemes for forming tarballs on places, as well as their subsequent verification.

At least this should apply to system-wide packages and popular packages, packages on which a large number of packages depend and the necessary functionality, especially such as xz-utils.

Trust networks need some sort of diversification (in a good way)

The following are possible attack vectors (some): blobs, including tarballs and archives in general.

[Elleni]

We have a manjaro VM that had no exposure of its ssh server to the internet, that had the affected version of 5.6.1 installed. Now when connecting to this vm through ssh (from within a secured corporate network, not from internet) - for example for administering it by an ansible server, is there any chance that the backdoor is spread to other machines, as long as they have not installed an affected ssh version anyway? Or is it enough to patch this client to a non-affected version of xz-utils?

[figueroa]

Courtesy of today's TLDR newletter, a timeline of the XZ attack:
https://research.swtch.com/xz-timeline?utm_source=tldrnewsletter
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

[Zucca]

[CaptainBlood]

[logrusx]

[Zucca]

[Elleni]

understood. Thanks for your replies, guys!

[modnaruved]

Thanks figueroa for providing interesting information.

During the reading, I thought: maybe this (backdooring) is done to distract attention? And/or is this a trial ball/balloon, one of?

[Hu]

Considering the likely impact an attacker could have if this backdoor were successfully used, I think this was the intended payload, not a distraction. A distraction would need to be noticed to be distracting, and the author seems to have taken significant effort to go unnoticed.

[salam]

Is it a common thing to mix source code and some binary mess? For me, this looks to be the biggest problem of the whole chain. The project cannot be considered open source any more. If foreign binary blob is allowed to be included in the compilation process, we can expect many more black boxes in linux hosts, doing random things.

[axl]

There are all sorts of binary data in source trees these days. This is a compressing lib; it's not unnatural to think it comes with an archive or two to test its own functionality. I imagine libjpeg comes with a jpeg file too. libpng with a png file. And so on.

Frankly, some things about this backdoor are sophisticated and advanced enough to be scary. The patience. The social engineering. The way it hides itself when you try to debug. But on the other hand, there are aspects of this that do not sit right with me at all. Why, if you invested so much time and energy, would you limit yourself to just x86_64? And as sophisticated as it is in hiding itself, still, must be a major oversight to be able to find it just by doing time sshd --help.

sshd --help shouldn't take 800ms. People are going to notice that. I mean no insult to the person that found it, but, its not something that can pass easily without being found.

Also, this is a passive backdoor. It doesn't call home, it waits for home to call to it. So, you would think, if someone had the technological expertise to pull this off, and the time, and the resources, they would find something better than just affecting JUST ssh, on JUST x86_64? I mean, you wait for 2 years to infect the world, and then, you do it just 1/2 of what you could have done. Seems a bit weird. Many of us do not expose ssh to the world to begin with. And might add that some of the world has moved on arm, so seems weird to choose by yourself if you gonna do something bad, you only gonna do it to part of the world.

And third thing I want to mention is that I am not sure how much we will be able to learn ourselves from the backdoor and this whole incident. But, on the other hand, we are a very wealthy mine of information for the people that did this and are looking at us to see how we will react. I think, there are multiple entities reading everything that was analysed and said about the whole incident and are making notes on how to make it better next time.

[szatox]

Dunno, kinda smells like a targeted attack. Passively waiting for instructions suggests it's not about size, but how you use it. Calling home is much more visible than just sitting tight waiting for instructions.
Could also be done as the ground-work by one of the 3-letter agencies, something to be used later when a target presents itself, but probably _not_ a botnet.

[axl]

[logrusx]

Don't turn this into chat please.

Best regards,
Georgi

[Hu]

[Zucca]

[colo-des]

[Hu]

Yes, that was its stated purpose, and for the non-malicious binary parts, was its true purpose. However, I recall reading a comment elsewhere criticizing the practice of committing binary data like this that has no reproduction process. That person advocated instead that there should exist a documented and reproducible path to regenerate the test data, and arrive at the same blobs that were actually committed. As an example of what that commenter could have meant, if the test is that the decompressor correctly rejects a corrupted file, then the reproduction path might be:

• Use seq 1 10000 to generate a file for compression.
• Compress it.
• Use dd bs=1 seek=N ...other-params to corrupt specific bytes in the compressed file from the previous step.
• Run the decompressor on the resulting damaged file and verify it fails as intended.

While the person committing these blobs may have followed those steps, the steps were not documented and committed, so no one could rerun them to verify that the blob really was just some corruption of an innocuous file. Once there was a pattern of committing blobs that downstream could not reproduce at will, the attacker could readily commit a non-reproducible malicious blob and expect that no one would notice it.

[Chiitoo]

For the architecture, indeed, why make things more complicated if you don't need more than a specific one?

All in all, at least at this point, it seems they were not after "infecting the whole world", but something more specific... but I doubt we'll ever know for sure.

Regarding test data, Lasse Collin (Larhzu at #tukaani / Libera) mentioned he created the test files of old mostly using a hexeditor (as mentioned in 'tests/files/README' [1]), but the newer ones were created using a generator(?) by Jia.

I also think it seems normal to have them, but the method they were being created there is not the way to do it (and Lasse was not happy about it either I believe).

1. https://git.tukaani.org/?p=xz.git;a=blob;f=tests/files/README;h=e987a5193194907a75fe38bb36106dfd3e0f115f
_________________
Kindest of regardses.

[salam]

I got the point with the legit test data, what worries me is the ability to include literally anything in the final binary. If the build chain is not locked down to the sources directory, that should contain only readable files, the backdoor could be able to pull that additional data from anywhere(would the same work if the binary was summoned by a tool like wget?). Something like in a container environment, mount only the directories required for building, disable network access, build the package and merge it if the task was a success.

[Hu]

Locking down the build environment is a good idea, but that is usually left to the distributor, rather than built into every package individually. This is safer, in part because if it was part of the package, a malicious developer could "accidentally" disable the lockdown, as Jia Tan apparently did with the test for Landlock support. When the distributor is responsible for the lockdown, we can assume that the malicious developer must actively work to escape it, rather than committing a deniable bug that prevents the lockdown from enforcing its rules.

To your point about wget, Portage's network-sandbox FEATURES entry would block that avenue. I don't know if the targeted distributions implement an equivalent sandbox.

[jpsollie]

Hello everyone,

My laptop/desktop/NAS have been using the xz-utils 5.6.0 package right from the start.
As such, they were potentially affected.
When this CVE was published, I immediately downgraded XZ, but:

1. Does it affect openssh binaries compiled with XZ as well? or only at runtime?
the idea is: let's assume I compiled a gentoo package for amd devices when xz 5.6.0 was being used,
will installing that precompiled binary automatically install the backdoor as well?

2. How can I activate the kill switch?
I read here: https://piaille.fr/@zeno/112185928685603910 that the following kill switch exists:

[logrusx]

When I read nonsense like this: