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

111–120 of 482 posts

Re: Timeline of the xz open source attack

#111

Post by jeltz »

tommiegannert wrote: post #29
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…

The Jigar Kumar nudges are so incredibly rude. I would have banned the account, but perhaps they contributed something positive as well that isn't mentioned. I wonder if it would be possible to crowdsource FOSS mailing list moderation.

I think that is intentional and that the goal would have been achieved even if Jigar (who probably is the same guy as Jia) had been banned.

Re: Timeline of the xz open source attack

#112

Post by jdsalaro »

riskable wrote: post #97
nrawe wrote: 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…

This event should be a wake-up call to businesses everywhere: It's not just a small number of "core" FOSS projects that need their support (funding and assistance!). Before this event who was thinking about a compression library when considering the security of their FOSS dependencies? The scope of "what FOSS needs to be supported and well-funded" just increased by an order of magnitude.

> This event should be a wake-up call to businesses everywhere

This ought to be not only a wake-up call for businesses, but also to hobbyists and members of the public in general; our code, our projects and our social "code-generating systems" must be hardened or face rampant abuse and ultimately be weaponised against us.

In a way, these issues which FOSS is facing and are becoming apparent are no different to those democracy been submitted since time immemorial.

Re: Timeline of the xz open source attack

#113

Post by apantel »

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.

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.

Re: Timeline of the xz open source attack

#114

Post by clnhlzmn »

jrochkind1 wrote: post #31

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

This is not Lasse Collin’s responsibility. What is a burnt out committer supposed to do? Absolutely nothing would be fine. Doing exactly what Lasse Collin did and turn over partial control of the project to an apparently helpful contributor with apparent community support is also perfectly reasonable.

Re: Timeline of the xz open source attack

#115

Post by singularity2001 »

phicoh wrote: post #98
zoeysmithe wrote: post #91

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…

You may want to read Kevin Mitnick on how (relatively) easy it is to infiltrate physical spaces.

Re: Timeline of the xz open source attack

#116

Post by duped »

chubot wrote: post #103

Something to add to the timeline: when did this avenue of attack become available? It only happened in the last 10 years apparently. Why do sshd and xz-utils share an address space? When was the sshd -> systemd dependency introduced? When was the systemd -> xz-utils dependency introduced? --- To me this ARCHITECTURE issue is actually bigger than the social engineering, the details of the shell script, and the details…

I don't think these questions are that interesting. SSHD shared an address space with xz-utils because xz utils provides a shared library, and that's how dynamic linking works. sshd uses libsystemd on platforms with systemd because systemd is the tool that manages daemons and services like sshd, and libsystemd is the bespoke way for daemons to talk to it (and more importantly, it is already there in the distro - so you're not "adding a million line dependency" so much as linking against a system library from the OS developers that you need).

Linking against libsystemd on Debian is about as suspicious as linking against libsystem on MacOS. It's a userspace library that you can hypothetically avoid, but you shouldn't.

As for why systemd links against xz, I don't know, and it's a bit surprising that an init system needs compression utils but not particularly surprising given the kitchen sink architecture of systemd.

Re: Timeline of the xz open source attack

#117

Post by JeremyNT »

chubot wrote: post #103

Something to add to the timeline: when did this avenue of attack become available? It only happened in the last 10 years apparently. Why do sshd and xz-utils share an address space? When was the sshd -> systemd dependency introduced? When was the systemd -> xz-utils dependency introduced? --- To me this ARCHITECTURE issue is actually bigger than the social engineering, the details of the shell script, and the details…

It's certainly a reasonable question to ask in this specific case. In hindsight Debian and Red Hat both bet badly when patching OpenSSH in a way that introduced the possibility of this specific supply chain attack.

> If so, we should be proactively removing and locking down other dependencies, because it will likely be an effective and simple mitigation.

I think this has always been important, and it remains so, but incidents like this really drive the point home. For any piece of software that has such a huge attack surface as ssh does, the stakes are even higher, and so the idea of introducing extra dependencies here should be approached with extreme caution indeed.

Re: Timeline of the xz open source attack

#118

Post by pluc »

The most interesting question I have with all this is:

Do you think this was a planned effort or was it opportunistic? Did they know what they were doing and social engineered towards it, or did they figure out what to do based on the day-to-day context they discovered?

Re: Timeline of the xz open source attack

#119

Post by denimnerd42 »

sebstefan wrote: post #90
userbinator wrote: post #86

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.

All things considered I'm not sure that'd be such a good thing How many security issues spring from outdated packages vs packages updated too hastily?

and when you do get a security issue and you're using a 10 year old version the upgrade is going to be really really difficult vs incremental upgrades when they are available. or are you going to fork and assume responsibility for that library code too?
Post reply on HN