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

51–60 of 482 posts

Re: Timeline of the xz open source attack

#51

Post by HPsquared »

lukaslalinsky wrote: post #24

The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into…

I'm reminded of the short story "The Strange Case of Mr Pelham", in which a man is stalked and eventually replaced by a doppelganger.

https://en.wikipedia.org/wiki/The_Strange_Case_of_Mr_Pelham

Re: Timeline of the xz open source attack

#52

Post by asvitkine »

XorNot wrote: post #8

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…

Well, test files shouldn't be affecting the actual production binary.

But in practice that's not something that can be enforced for arbitrary projects without those projects having set something up specifically.

For example, the project could track the effect on binary size of the production binary after every PR. But then it still requires a human (or I guess an AI bot?) to notice that the increase would be unexpected.

Re: Timeline of the xz open source attack

#53

Post by [deleted] »

arrowsmith wrote: post #39
wufocaculura wrote: post #14

Earlier quoted context omitted.

There's a single dot in a line between #include and void my_sandbox(void). It is easy to miss, but makes the compile to fail, thus resulting in HAVE_LINUX_LANDLOCK to be never enabled.

Can someone explain to n00bs like me: what's "landlock" anyway and why is it significant here?

[deleted]

Re: Timeline of the xz open source attack

#54

Post by jvanderbot »

> It's also good to keep in mind that this is an unpaid hobby project.

That's the root cause. At some point a corp/gov consortium needs to adopt key projects and hire out the maintainers and give them real power and flexibility, perhaps similar to the way a nation might nationalize key infrastructure.

But this is against the core ethos at some level. Freedom and safety can be antagonistic.

Re: Timeline of the xz open source attack

#55

Post by kashyapc »

rsc wrote: post #45
exacube wrote: post #38

Is the real identity of Jia Tan known, even by Lasse Collin? I would think a "real identity" should be required by linux distros for all /major/ open source projects/library committers which are included in the distro, so that we can hold folks legally accountable

Open source fundamentally does not work that way. There are many important open source contributors who work pseudonymously. Google's Know, Prevent, Fix blog post floated the idea of stronger identity for open source in https://security.googleblog.com/2021/02/know-prevent-fix-fra... and there was very significant pushback. We learned a lot from that. The fundamental problem with stronger identity is that spy agencies…

While "open source" fundamentally doesn't work that way, the point here is about maintainers, not regular contributors. Identity of new maintainers must be vetted (via in-person meetups and whatever other mechanisms) by other "trusted" maintainers whose identities are "verified".

I realize, it's a hard problem. (And, thanks for the link to the "Know, Prevent, Fix" post.)

PS: FWIW, I "win my bread" by working for a company that "does" open source.

Edit: Some projects I know use in-person GPG key signing, or maintainer summits (Linux kernel), etc. None of them are perfect, but raises the bar for motivated anonymous contributors with malicious intent, wanting to become maintainers.

Re: Timeline of the xz open source attack

#56

Post by uluyol »

rsc wrote: post #40
jrochkind1 wrote: post #31

This seems very difficult to defend against. What is a project with a single burnt-out committer to do?

lcamtuf's two posts argue that this may simply not be an open-source maintainer's job to defend against. ("The maintainers of libcolorpicker.so can’t be the only thing that stands between your critical infrastructure and Russian or Chinese intelligence services. Spies are stopped by spies.") That doesn't mean we shouldn't try to help burnt out committers, but the problem seems very hard. As lcamtuf also says, many th…

There are efforts from industry to try to secure open source, e.g., https://cloud.google.com/security/products/assured-open-sour...

I suspect some variant of this will grow so that some companies, MS/GitHub for example, audit large body of code and vet it for everyone else.

Re: Timeline of the xz open source attack

#57

Post by Denvercoder9 »

dhx wrote: post #17
daghamm wrote: post #5

Earlier quoted context omitted.

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?

An attack would look something like: 1. A new "test" is added to the xz-utils repository, and when xz is being built by a distribution such as Debian, the backdoor from the "test" is included into the xz binary. 2. The backdoored xz is distributed widely, including to a target vendor who wishes to from a Debian development environment compile a kernel for an embedded device that is usually used in a specific industry…

Note that none of these steps require the attacker to have any code in the kernel. The kernel patchset is completely orthogonal to the possibility of this attack, and seems to be benign.

Re: Timeline of the xz open source attack

#58

Post by nrvn »

rsc wrote: post #45
exacube wrote: post #38

Is the real identity of Jia Tan known, even by Lasse Collin? I would think a "real identity" should be required by linux distros for all /major/ open source projects/library committers which are included in the distro, so that we can hold folks legally accountable

Open source fundamentally does not work that way. There are many important open source contributors who work pseudonymously. Google's Know, Prevent, Fix blog post floated the idea of stronger identity for open source in https://security.googleblog.com/2021/02/know-prevent-fix-fra... and there was very significant pushback. We learned a lot from that. The fundamental problem with stronger identity is that spy agencies…

I was initially thinking that one of the core non-tech causes of the was the single-person maintenance mode of the xz project.

But you have a point. As an agency you can seed two jiatan's to serve diligently for a couple of years following the strict 2-person code reviews and then still poison the project. On the other hand, if the xz build process was automated and transparent and release artifacts were reproducible and verifiable even in this poor condition of xz-utils as a project it would have been much harder to squeeze in a rogue m4/build-to-host.m4

Re: Timeline of the xz open source attack

#59

Post by Thorrez »

wufocaculura wrote: post #14
thrdbndndn wrote: post #9

How do you get "Jigar Kumar"'s email address? I can't seem to find it in the (web version of) the maillist. Another question: What is the typo exactly in this commit? I can't seem to find it. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...

There's a single dot in a line between #include and void my_sandbox(void). It is easy to miss, but makes the compile to fail, thus resulting in HAVE_LINUX_LANDLOCK to be never enabled.

prctl, not prcntl

Re: Timeline of the xz open source attack

#60

Post by NarcissistDev »

lukaslalinsky wrote: post #24

The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into…

Thank the lord Lasse wasn’t maintaining the nuclear codes.

In another thought, I hope the nukes aren’t on a rolling Debian distro.

Post reply on HN