Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

101–110 of 482 posts

Re: Timeline of the xz open source attack

#101
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…

That's just the nature of free software- you have to either trust the maintainer or do it yourself. There is not really a way around it.

- Corporate maintainers are great until they enshittify things in the pursuit of profit (see Oracle)

- Nonprofits are probably the best but can go the same route as corps (see Mozilla)

- Hobbyists are great until they burnout (see xz)

Re: Timeline of the xz open source attack

#102

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.

Not surprising, unfortunately. You'd think malicious actors would be nice to people they're trying to deceive. But after watching a few Kitboga videos, I learned that they more often yell, abuse, and swear at their victims instead.

Re: Timeline of the xz open source attack

#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 of the payload.

I believe that for most of the life of xz-utils, it was a "harmless" command line tool.

In the last 10 years, a dependency was silently introduced on some distros, like Debian and Fedora.

Now maintainer Lasse Collin becomes a target of Jia Tan.

If the dependency didn't exist, then I don't think anyone would be bothering Collin.

---

I asked this same question here, and got some good answers:

https://lobste.rs/s/uihyvs/backdoor_upstream_xz_liblzma_lead...

Probably around 2015?

So it took ~9 years for attackers to find this avenue, develop an exploit, and create accounts for social engieering?

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

Re: Timeline of the xz open source attack

#104

Earlier quoted context omitted.

I think it is unauthenticated from the point of view of SSH’s own authentication. The backdoor has its own credential, but the RCE is accessible if you don’t have an account on the system.

That's the basis for my preferring the term relating to authorization. The two terms have distinct and well-defined meanings in the domain. They're both critical aspects of security but for different reasons.

Remote code execution already implies unauthorized. There is no such thing as authorized remote code execution.

Re: Timeline of the xz open source attack

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

Yeah, as I note elsewhere in this thread, the OpenSSL "Heartbleed" saga should've taught some lessons, but alas, it's "classic" human nature to repeat our mistakes.

Re: Timeline of the xz open source attack

#106

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’ve given semi-popular projects that I no longer had the bandwidth to maintain to random people who bothered to email, no pressuring needed. While those projects are probably four to five magnitudes less important than xz, still thousands of people would be affected if the random dude who emailed was malicious. What should I have done? Let the projects languish? Guess I’ll still take the chance in the future.

Re: Timeline of the xz open source attack

#107
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…

tbf, most security issues aren't from some insider, but outsiders discovering exploits. The insider scenario here is extremely rare both in commercial and FOSS software.

Corporate insiders do stuff like this too, its just how often do we hear about it? FOSS has high visibility but closed source doesn't. Think of all the shady backdoors out there. Or what Snowden and others revealed.

On average a 100% FOSS organization is going to be much, much more secure than a 100% commercial close source one. Think of all the effort it takes to moderately secure a Windows/closed source stack environment. Its an entire massive industry! Crowdstrike alone has a $76bn marketcap and that's just one AV vendor!

Commercial software obeys the dictates of modern capitalism. Projects get rushed, code review and security take a backseat to quarterly reports and launch dates, etc. This makes closed source security issues common.

Usually when the exploit is discovered the attacker is far outside the victim's jurisdiction. See all the crypto gangs operating from non-Western non-extradition states.

Re: Timeline of the xz open source attack

#108
Timeline reads like a "pig butchering" or romance scam. Except the goal is not money, but control.

Attackers find a vulnerable but critical library in the supply chain. Do a cross check on maintainers or owners of the code (reference social media and other sources to get more information). Execute social engineering attack. Talk to maintainer(s) "off list" to gain rapport. Submit a few non-consequential patches that are easy to grep to gain trust. Use history of repository or mailing list against victim to gaslight ("last release was X years ago!1", "you are letting project rOt!", "community is waiting for you!").

Re: Timeline of the xz open source attack

#109
post #101
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…

That's just the nature of free software- you have to either trust the maintainer or do it yourself. There is not really a way around it. - Corporate maintainers are great until they enshittify things in the pursuit of profit (see Oracle) - Nonprofits are probably the best but can go the same route as corps (see Mozilla) - Hobbyists are great until they burnout (see xz)

I think the level of complexity is the problem. A bad actor can be embedded in any of the above contexts: corp, non-profit, FOSS hobbyist. It doesn’t matter. The question is: when software is so complex that no one knows what 99.9% of the code in their own stack, on their own machine, does (which is the truth for everyone here including me), how do you detect ‘bad action’?

Re: Timeline of the xz open source attack

#110
post #88

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…

Look how brilliantly they selected their target project: (1) xz and the lib are widely used in the wild including linux kernel, systemd, openSSH; (2) single maintainer, low rate of maintenance; (3) the original maintainer has other problems in his life distracting them from paying closer attention to the project. I am wondering how many other OSS projects look similar and can be targeted in similar ways?

Yes it seems a lot like a case of a predator picking off a weak and sick individual.
Post reply on HN