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

271–280 of 482 posts

Re: Timeline of the xz open source attack

#271

Post by pera »

psanford wrote: post #193

One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.

While I do agree that M4 is not great I don't believe any alternative would have prevented this attack: you could try translating that build-to-host file to say python with all the evals and shell oneliners and it would still not be immediately obvious for a distro package maintainer doing a casual review after work: for them it would look just like your average weekend project hacky code. Even if you also translated the oneliners it wouldn't be immediately obvious if you were not suspicious. My point is, you could write similarly obfuscated code in any language.

Re: Timeline of the xz open source attack

#272

Post by saghm »

coldpie wrote: post #96
Aurornis wrote: post #87

Earlier quoted context omitted.

The attackers will leverage any culture that helps them accomplish their goals. If being rude and pushy doesn’t work, the next round will be kind and helpful. Don’t read too much into the cultural techniques used, because the cultural techniques will mirror the culture at the time.

Even if the security outcome is the same, I would still count people being kind and helpful online instead of rude as an improvement.

As always, there's an xkcd for that https://xkcd.com/810/

Re: Timeline of the xz open source attack

#273

Post by rwmj »

itslennysfault wrote: post #177
rwmj wrote: post #61

Missing the whole Fedora timeline. I was emailed by "Jia Tan" between Feb 27 and Mar 27, in a partially successful attempt to get the new xz into Fedora 40 & 41. Edit: I emailed Russ with the details.

I wondered about this. I saw the note at the bottom "RedHat announces that the backdoored xz shipped in Fedora Rawhide and Fedora Linux 40 beta" but saw nothing in the timeline explaining when/how it made it into Fedora.

These are the Fedora packages for xz that are vulnerable. If you click through the links you can see when they were added:

https://lists.fedoraproject.org/archives/list/devel@lists.fe... (https://archive.ph/diGNB)

This is the rough sequence of events in Fedora:

https://lists.fedoraproject.org/archives/list/devel@lists.fe... (https://archive.ph/e0SdX)

Re: Timeline of the xz open source attack

#274

Post by maerF0x0 »

lmkg wrote: post #268
maerF0x0 wrote: post #258

Two points I'd be interested in discussing. 1. It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way (and selected for their access). Why play the long game of let's find a lone package, w/ a tired maintainer, and then try to get in good with them vs. Let's survey all packages w/ a tired ma…

Regarding point 1: The timeline in the linked article describes some communications as "pressure emails." I've heard the theory, but haven't seen solid evidence, that the pressure emails weren't just regular impatience from outside devs, but actually part of the attack . To convince the primary maintainer into granting access to another party.

Occams Razor and a variation on Hanlon's razor to me suggest that Jia actually wanted to solve the issues and work on code. They contributed some things to other repos too, correct? (I saw another thread about microsoft documentation, for eg).

Here's the thing, if the maintainer was so tired and needed the help, the pressure is more risk than reward. The maintainer would be relieved to have help... But pressure risks estranging...

To be clear I'm aware this is just my own musing though.

Re: Timeline of the xz open source attack

#275

Post by publius_0xf3 »

sebstefan wrote: post #69

Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.

I want to caution against taking a good thing too far.

There's a certain kind of talented person who is all too conscious of their abilities and is arrogant, irascible, and demanding as a result. Linus Torvalds, Steve Jobs, Casey Muratori come to mind. Much as we might want these characters to be kinder, their irascibility is inseparable from their more admirable qualities.

Sometimes good things, even the best things, are made by difficult people, and we would lose a lot by making a community that alienates them.

Re: Timeline of the xz open source attack

#276

Post by pixl97 »

TacticalCoder wrote: post #206
pixl97 wrote: post #187

Earlier quoted context omitted.

>It's either in source form and reproducable or it's not there. Wanna know how I know you haven't read into the discussion much? There are a whole lot of binary test cases in software. Especially when you're dealing with things like file formats and test cases that should specifically fail on bad data of particular types.

> There are a whole lot of binary test cases in software. That's not how I read GP's point. If even binary blobs in test cases are a place where backdoors are, now as a matter of fact, hidden then, certainly, among the folks advocating for binary drivers in FOSS, there are some who are already --or planning to-- add backdoors there. Binary blobs are all terrible, terrible, terrible ideas. Builds should be 100% reprod…

Then you figure out how to build a 'source' test case of a bad zip, or bad jpg, or word document or whatever else exists out there. Also figure out how to test that your bit4bit perfect binary isn't doing the wrong damned thing in your environment with actual real data.

Re: Timeline of the xz open source attack

#277

Post by tomxor »

usefulcat wrote: post #266
tomxor wrote: post #245

Earlier quoted context omitted.

That would be an improvement for sure... but this is not fundamentally a technical problem. Reading the timeline, the root cause is pure social engineering. The technical details could be swapped out with anything. Sure there are aspects unique to xz that were exploited such as the test directory full of binaries, but that's just because they happened to be the easiest target to implement their changes in an obfuscat…

> Is the real problem here handing over substantial trust to an anonymous contributor? Unless there's some practical way of comprehensively solving The Real Problem Here, it makes a lot of sense to consider all reasonable mitigations, technical, social or otherwise. > If a person has more to lose than maintainership then would this have happened? I guess that's one possible mitigation, but what exactly would that loo…

> I guess that's one possible mitigation, but what exactly would that look like in practice? Good luck getting open source contributors to accept any kind of liability. Except for the JiaTans of the world, who will be the first to accept it since they will have already planned to be untouchable.

It's not necessary to accept liability, that's waived in all FOSS licenses. What I'm suggesting would only risk reputation of non-malicious contributors, and from what I've seen, most of the major FOSS contributors and maintainers freely use their real identity or associate it with their pseudonym anyway, since that attribution comes with real life perks.

Disallowing anonymous pseudonyms would raise the bar quite a bit and require more effort from attackers to construct or steal plausible looking online identities for each attack, especially when they need to hold up for a long time as with this attack.

Re: Timeline of the xz open source attack

#278

Post by nebulous1 »

maerF0x0 wrote: post #258

Two points I'd be interested in discussing. 1. It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way (and selected for their access). Why play the long game of let's find a lone package, w/ a tired maintainer, and then try to get in good with them vs. Let's survey all packages w/ a tired ma…

Completely conclusive proof? No, but it seems unlikely that there ever would be conclusive proof of such.

They don't seem to exist outside of this incident and things related to this.

There were multiple people who also don't seem to exist outside of their posts to the xz mailing list applying pressure for the original maintainer to bring Jia on board. This occurred around the time that Jia was first making contact with the project, not only recently.

Apparently the IP addresses that were logged for Jia is a VPN based in Singapore

They have vanished.

Honestly, there's very little evidence that they weren't always intending this.

Re: Timeline of the xz open source attack

#279

Post by eadmund »

kibwen wrote: post #197
psanford wrote: post #193

One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.

That's a great first step, but ready your pitchforks for this next take, because the next step is to completely eliminate Turing-complete languages and arbitrary I/O access from standard build systems. 99.9% of all projects have the capability to be built with trivial declarative rulesets.

I think that what we need is good sandboxing. All a sandboxed Turing-complete language can do is perform I/O on some restricted area, burn CPU and attempt to escape the sandbox.

I would like to see this on the language level, not just on the OS level.

Re: Timeline of the xz open source attack

#280

Post by doakes »

nebulous1 wrote: post #278
maerF0x0 wrote: post #258

Two points I'd be interested in discussing. 1. It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way (and selected for their access). Why play the long game of let's find a lone package, w/ a tired maintainer, and then try to get in good with them vs. Let's survey all packages w/ a tired ma…

Completely conclusive proof? No, but it seems unlikely that there ever would be conclusive proof of such. They don't seem to exist outside of this incident and things related to this. There were multiple people who also don't seem to exist outside of their posts to the xz mailing list applying pressure for the original maintainer to bring Jia on board. This occurred around the time that Jia was first making contact w…

What's your source for the IP addresses?
Post reply on HN