Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

321–330 of 482 posts

Re: Timeline of the xz open source attack

#321

> 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.

> gov consortium Personally I wouldnt trust a govt to not backdoor everything.

A consortium is a great way to get money and power into those maintainers. Never said they should take the power from them or provide code. I think people are hearing their own mind here, not mine.

Re: Timeline of the xz open source attack

#322

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.

The Jia Tan character was never rude. If you make rudeness the thing that throws a red flag, then ‘nice’ fake accounts will bubble up to do the pressuring.

Jia Tan wasn't rude, but the original maintainer Laser Collin probably wouldn't have been as burned out and willing to give responsibility to them if the community wasn't as rude and demanding of someone doing free work for them.

I think we need to start paying more of these open source maintainers and have some staff/volunteers that can help them manage their git hub issue volume.

Re: Timeline of the xz open source attack

#323

> 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.

You are implying that governments are more technically competent and more trustworthy than open source communities..

Many open source projects often already do receive US government funding, mostly through an onerous grant-application process. Nationalizing American open source projects could make them operate more like European open source where their EU funding is open and clear. The detrimental trade-off, however, is that the American agencies most capable to support and contribute directly to infrastructure security have burned away all trust from the rest of the world. Direct contributions directly from those USG agencies would reduce global trust in those projects even worse.

Re: Timeline of the xz open source attack

#324

I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.

Wouldn't that just result in exploits written for old versions? A successful exploit for something that everyone is running might be worse, than a backdoor on blending edge systems.

Everyone being on different versions results in something like a moving target

Re: Timeline of the xz open source attack

#325
post #78

"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…

Sorta but flawed relevant xkcd: https://xkcd.com/2347/ I don't see how this is any strongly different than some unappreciated skill worker in a corporation. Its interesting the double standard we have for FOSS. Meanwhile in the commercial world, supply chain attacks are commonplace and barely solicit headlines. Yes, FOSS needs to be able to address these kinds of attacks, but the world runs on the efforts of the low-…

If you're not getting paid then it's just a hobby. And there's nothing wrong with hobbies. As a FOSS contributor myself I feel no obligation to promote FOSS adoption. Quality, security, and professionalism are not my problem; anyone who cares about those things is welcome to fork my code.

Re: Timeline of the xz open source attack

#326

I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.

well, it's the bazaar vs the cathedral, isn't it? bazaar moves a lot faster. Everyone likes that part, except when it breaks things, and when they have to chase an upstream that's constantly churning, etc. but most people don't consider that a cathedral itself might have some engineering merit too. cathedrals are beautiful and polished and stable.

I highly encourage people to try freeBSD sometime. Give ports a try (although the modern sense is that poudrie is better even if you want custom-built packages). See how nicely everything works. All the system options you need go into rc.conf (almost uniformly). Everything is documented and you can basically operate the system out of the FreeBSD Handbook documentation (it's not at all comparable to the "how to use a window or a menu" level intro stuff the linux provides). You can't do that when everything is furiously churning every release. everything just works, everything is just documented, it's an experience when you're coming from linux.

and that forum post from 2007 on how to tweak a service script is probably still valid, because BSD hasn't had 3 different init systems over that timespan etc.

just like "engineering is knowing how to build a bridge that barely doesn't fall over", engineering here is knowing what not to churn, and fitting your own work and functionality extensions into the existing patterns etc. like it doesn't have to be even "don't make a bigger change than you have to", you just have to present a stable userland and stable kernel interface and stable init/services interface. the fact that linux doesn't present a stable kernel interface is actually fairly sketchy/poor engineering, it doesn't have to be that way, a large subset of kernel interfaces probably should be stable.

Re: Timeline of the xz open source attack

#327
post #17

Earlier quoted context omitted.

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.

Yeah, but gaining trust with benign patchset would be the first step.

Re: Timeline of the xz open source attack

#328

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.

This doesn't read as a technical failure to me. This was 99% social engineering. I understand that the build system was used a vector, but eliminating that vector doesn't mean all doors are closed. The attacker took advantage of someone having trouble.

Re: Timeline of the xz open source attack

#329

Earlier quoted context omitted.

Yes the whole "let's take a mystery meat tarball from a repo that isn't the project repo" seems suspect. Github+ even has a scheme for signing artifacts such that you have some level of trust they came from inside their Actions system, derived from some git commit. This would allow the benefits of a modular build for a large product like a distro, while preserving a chain of trust in its component parts. +Not advocat…

as I wrote in a different thread, some projects don't have any source control. From the big ones - 7z, ncurses are both tarballs only.

They need to join us in the 80s and start using source control.

Re: Timeline of the xz open source attack

#330
post #98

Earlier quoted context omitted.

Sorta but flawed relevant xkcd: https://xkcd.com/2347/ I don't see how this is any strongly different than some unappreciated skill worker in a corporation. Its interesting the double standard we have for FOSS. Meanwhile in the commercial world, supply chain attacks are commonplace and barely solicit headlines. Yes, FOSS needs to be able to address these kinds of attacks, but the world runs on the efforts of the low-…

I think there is a fundamental difference between how corporations used to work and how open source typically works. In a traditional corporation, people would come to an office. It would be known where they live. If you would require something like (code) review, it becomes a lot harder to plant something. Obviously not impossible, but hard for all but the most dedicated attackers. In contrast, with open source and…

True, but we have to assume that nation states are now actively inserting or recruiting intelligence agents in prominent tech companies. US authorities already caught a Saudi spy in Twitter. How many haven't been caught yet? If I was running foreign intelligence for China or Israel or any other major country I would certainly try to place agents into Google, Apple, OpenAI etc.
Post reply on HN