Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

91–100 of 482 posts

Re: Timeline of the xz open source attack

#91
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-level few, generally. The percent of people who work to build and maintain core infrastructure has always been small in any economic system. The world is held up by the unsung labor of the anonymous working class. Think of all the people working right now to make sure you have clean water, electricity, sanitation, etc. Its a tiny fraction of the people in your city.

Conversely, why aren't all these corporations who depend on this contributing themselves? Or reaching out? There's a real parasitic aspect here that gets swept under the rug too.

I'd even argue this isn't really a hobby for many, especially for higher profile projects. For many its done for social capital reasons to build up one's reputation which has all sorts of benefits, including corporate advancement, creating connections for startups, etc. Its career adjacent. And that's ignoring all the companies that contribute to FOSS explicitly with on-the-clock staff.

So there are motivators more than just "I'm bored and need a hobby." Its a little dismissive to call FOSS development just a hobby. Is what Linus does a hobby? I don't think most people would think so. Things like this have important social and economic motivators. The hypothetical guy in the comic isn't some weirdo doing something irrationally, but has rational motivators.

I'd also argue that its pretty harmful to FOSS adoption if the community takes on a "well, its a hobby don't expect quality, security, or professionalism." This is a great way to chase people away from FOSS. We can't just say "Oh FOSS is better than much closed software" when things are good, then immaturely reply "its just a dumb hobby, you're dumb for trusting me," when things go south. I think its pretty obvious there's a lot of defensiveness right now and people being protective over their social capital and projects, but I think this path is just the wrong way to go.

Comms, PR, and image management in FOSS is usually bad (see Linus's rage, high profile flame wars, dramatic forkings, ideological battles, etc), so optics here aren't great, because optics is something FOSS struggles with. The community is at best, herding cats, with all manner of big personalities and egos, and its usually a bit of a controlled car crash on the best of days.

Re: Timeline of the xz open source attack

#92
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

If this was done by a state actor then this policy wouldn't help at all. States have no shortage of identities to fake.

Re: Timeline of the xz open source attack

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

I think a problem is that there doesn't seem any way to automatically check this. If we assume that anything that is used during build time can be malicious then figuring out those dependencies is already hard enough. Mapping that to organizational stability is one step further.

Re: Timeline of the xz open source attack

#95
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?

I'm thinking 95% of home automation which is full of obscure devices and half baked solutions which get patched up by enthusiasts and promptly forgotten about.

Controlling someone's lights is probably less important than Debian's build fleet but it's a scary proposition for the impacted individual who happens to use one of those long tail home assistant integrations or whatever.

Re: Timeline of the xz open source attack

#96

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

Re: Timeline of the xz open source attack

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

Re: Timeline of the xz open source attack

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

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 poorly funded projects. People don't always have money to travel. So the people working on an open source project may only know each other by some online handles. Nerds typically don't like video conferencing. So it is quite possible to keep almost everything about an identity secret.

And that makes it a lot more attractive to just try something. If something goes wrong, the perpetrator is likely in a safe jurisdiction.

Re: Timeline of the xz open source attack

#99
Given this disaster, one or other "foundation" will now embrace the `xz` project, start paying a maintainer or two so that they don't accidentally end up dying from burnout.

Rinse, repeat for all critical-path open source software. A bit like the OpenSSL "Heartbleed" disaster[1]. OpenSSL is now part of Linux Foundation's (they do a lot of great work) "Core Infrastructure Initiative".

Many fat companies build their applications on these crucial low-level libraries, and leave the drudgery to a lone maintainer in Nebraska, chugging away in his basement[2].

[1] https://en.wikipedia.org/wiki/Heartbleed

[2] https://xkcd.com/2347/

Re: Timeline of the xz open source attack

#100
post #3

I think this analysis is more interesting if you consider these two events in particular: 2024-02-29: On GitHub, @teknoraver sends pull request to stop linking liblzma into libsystemd.[1] (not in the article) 2024-03-20: The attacker is now a co-contributor for a patchset proposed to the Linux kernel, with the patchset adding the attacker as a maintainer and mirroring the attacker's activity with gaining the trust ov…

I don't think the attacker saw the systemd change at all personally.

The way the exploit was setup, they could have pivoted to targeting basically any application server because there's so many interdependencies. python, php and ruby could be targeted because liblzma is loaded via libxml2 as an example.

Gaining trust for linux kernel commits would have just let them continue maximizing profit on their time investment.

>particularly if the attacker intended to target embedded systems (such as military transport vehicles [6])

Said vehicles aren't networked on the public internet and from experience in this particular sector, probably haven't been nor will be updated for decades. "Don't break what isn't broken" applies as well as "military doesn't have a budget to pay defense contractors $1 million to run apt-get update per vehicle".

Post reply on HN