Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

Post reply on HN
Print view View original

1–10 of 482 posts

Re: Timeline of the xz open source attack

#2

Post by goombacloud »

This might not be complete because this statement "More patches that seem (even in retrospect) to be fine follow." lacks some more backing facts. There were more patches before the SSH backdoor, e.g.: "Lasse Collin has already landed four of Jia Tan’s patches, marked by “Thanks to Jia Tan”" and the other stuff before and after the 5.4 release. So far I didn't see someone make a list of all patches and gather various opinions on whether the changes could be maliciously leveraged.

Re: Timeline of the xz open source attack

#3

Post by dhx »

I think this analysis is more interesting if you consider these two events in particular:

2024-02-29: On GitHub, @teknoraver sends pull request to stop linking liblzma into libsystemd.[1]

(not in the article) 2024-03-20: The attacker is now a co-contributor for a patchset proposed to the Linux kernel, with the patchset adding the attacker as a maintainer and mirroring the attacker's activity with gaining the trust over the development of xz-utils.

A theory is that the attacker saw the sshd/libsystemd/xz-utils vector as closing soon with libsystemd removing its hard dependency on xz-utils. When building a Linux kernel image, the resulting image is compressed by default with gzip [3], but can also be optionally compressed using xz-utils (amongst other compression utilities). There's a lot of distributions of Linux which have chosen xz-utils as the method used to compress kernel images, particularly embedded Linux distributions.[4] xz-utils is even the recommended mode of compression if a small kernel build image is desired.[5]

If the attacker can execute code during the process of building a new kernel image, they can cause even more catastrophic impacts than targeting sshd. Targeting sshd was always going to be limited due to targets not exposing sshd over accessible networks, or implementing passive optical taps and real time behavioural analysis, or receiving real time alerts from servers indicative of unusual activity or data transfers. Targeting the Linux kernel would have far worse consequences possible, particularly if the attacker intended to target embedded systems (such as military transport vehicles [6]) where the chance of detection is reduced due to lack of eyeballs looking over it.

[1] https://github.com/systemd/systemd/pull/31550

[2] https://lkml.org/lkml/2024/3/20/1004

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[4] https://github.com/search?q=CONFIG_KERNEL_XZ%3Dy&type=code

[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[6] https://linuxdevices.org/large-military-truck-runs-embedded-...

Re: Timeline of the xz open source attack

#4

Post by goombacloud »

goombacloud wrote: post #2

This might not be complete because this statement "More patches that seem (even in retrospect) to be fine follow." lacks some more backing facts. There were more patches before the SSH backdoor, e.g.: "Lasse Collin has already landed four of Jia Tan’s patches, marked by “Thanks to Jia Tan”" and the other stuff before and after the 5.4 release. So far I didn't see someone make a list of all patches and gather various…

In https://archive.softwareheritage.org/browse/revision/e446ab7... one can open the patches and then click the "Changes" sub-tab. Stuff like this looks like a perf improvement but who knows if a tricky bug is introduced that was aimed to be exploited https://archive.softwareheritage.org/browse/revision/e446ab7... There are more patches to be vetted unless one would give up and say that 5.2 should be used as last "known-good".

Re: Timeline of the xz open source attack

#5

Post by daghamm »

dhx wrote: post #3

I think this analysis is more interesting if you consider these two events in particular: 2024-02-29: On GitHub, @teknoraver sends pull request to stop linking liblzma into libsystemd.[1] (not in the article) 2024-03-20: The attacker is now a co-contributor for a patchset proposed to the Linux kernel, with the patchset adding the attacker as a maintainer and mirroring the attacker's activity with gaining the trust ov…

I don't understand how this could have worked.

If you compile and build your own image, would that be able to trigger the backdoor?

You can of course change an existing image to something that triggers the backdoor, but with that level of access you won't really need a backdoor, do you?

Re: Timeline of the xz open source attack

#6

Post by bandrami »

daghamm wrote: post #5
dhx wrote: post #3

I think this analysis is more interesting if you consider these two events in particular: 2024-02-29: On GitHub, @teknoraver sends pull request to stop linking liblzma into libsystemd.[1] (not in the article) 2024-03-20: The attacker is now a co-contributor for a patchset proposed to the Linux kernel, with the patchset adding the attacker as a maintainer and mirroring the attacker's activity with gaining the trust ov…

I don't understand how this could have worked. If you compile and build your own image, would that be able to trigger the backdoor? You can of course change an existing image to something that triggers the backdoor, but with that level of access you won't really need a backdoor, do you?

It's Thompson's "Trusting Trust"[1], right? To the extent XZ is part of the standard build chain you could have a source-invisible replicating vulnerability that infects everything. And if it gets into the image used for, say, a popular mobile device or IoT gadget...

1: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Re: Timeline of the xz open source attack

#8

Post by XorNot »

What stands out to me is this particular justification:

> 2024-02-23: Jia Tan merges hidden backdoor binary code well hidden inside some binary test input files. The associated README claims “This directory contains bunch of files to test handling of .xz, .lzma (LZMA_Alone), and .lz (lzip) files in decoder implementations. Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves.”

This is, perhaps, the real thing we should think about fixing here because the justification is on the surface reasonable and the need is quite reasonable - corrupted test files to test corruption handling.

But there has got to be some a way to express this which doesn't depend on, in essence, "trust me bro" since binary files don't appear in diffs (which is to say: I can think of a number of means of doing it, but there's definitely no conventions in the community I'm aware of).

Post reply on HN