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

211–220 of 482 posts

Re: Timeline of the xz open source attack

#211

Post by koito17 »

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.

In this case, I think the GP is absolutely right. If you look at the infamous patch with a "hidden" dot, you may think "any C linter should catch that syntax error and immediately draw suspicion." But the thing is, no linter at the moment exists for analyzing strings in a CMakeLists.txt file or M4 macro. Moreover, this isn't something one can reliably do runtime detection for, because there are plenty of legitimate reasons that program could fail to compile, but our tooling does not have a way to clearly communicate the syntax error being the reason for a compilation failure.

Re: Timeline of the xz open source attack

#212

Post by 01HNNWZ0MV43FF »

Eisenstein wrote: post #150
apantel wrote: post #109

Earlier quoted context omitted.

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’?

The level of complexity involved in making sure that electrical plants work, that water gets to your home, that planes don't crash into each other, that food gets from the ground to a supermarket shelf, etc, is unfathomable and no single person knows how all of it works. Code is not some unique part of human infrastructure in this aspect. We specialize and rely on the fact that by and large, people want things to wor…

> Code is not some unique part of human infrastructure in this aspect

It kinda is. The fact that code costs fractions of a penny to copy and scale endlessly, changes everything.

There's hard limits on power plants, you need staff to run them, it's well-understood.

But software - You can make a startup with 3 people and a venture capitalist who's willing to gamble a couple million on the bet that one really good idea will make hundreds of millions.

Software actually is different. It's the only non-scarce resource. Look at the GPL - Software is the only space where communism / anarchy kinda succeeded, because you really can give away a product with _nearly_ no variable costs.

And it's really just the next step on the scale of "We need things that are dangerous" throughout all history. Observe:

- Fire is needed to cook food, but fire can burn down a whole city if it's not controlled

- Gunpowder is needed for weapons, but it can kill instantly if mishandled

- Nuclear reactors are needed for electricity, but there is no way to generate gigawatts of power in a way that those gigawatts can't theoretically cause a disaster if they escape containment

- Lithium-ion batteries are the densest batteries yet, but again they have no moral compass between "The user needs 10 amps, I'm giving 10 amps" and "This random short circuit needs 10 amps, I'm giving 10 amps"

- Software has resulted in outrageous growth and change, but just like nuclear power, it doesn't have its own morality, someone must contain it.

Even more so than lithium and nuke plants, software is a bigger lever that allows us to do more with less. Doing more with less simply means that a smaller sabotage causes more damage. It's the price of civilization.

So the genie ain't going back in. And private industry is always going to be a tragedy of the commons.

I'm not sure what government regulation can do, but there may come a point where we say, even if it means our political rivals freeload off of us, it's better for the USA to bear the cost of auditing and maintaining FOSS than to ask private corporations to bear that cost duplicating each other's work and keeping it secret.

Is that a handout to Big Tech? 100%. Balance it with UBI and a CO2 tax that coincidentally incentivizes data centers to be efficient. We'll deal with it.

Re: Timeline of the xz open source attack

#213

Post by Dalewyn »

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.

[flagged]

Re: Timeline of the xz open source attack

#214

Post by GoblinSlayer »

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.

Just don't do anything crazy. There are legitimately crazy people asking for crazy things, not necessarily backdoors.

Re: Timeline of the xz open source attack

#215

Post by smallmancontrov »

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.

What does modern C project management look like? I'm only familiar with Autotools and CMake.

Re: Timeline of the xz open source attack

#216

Post by galleywest200 »

pixl97 wrote: post #184
mseepgood wrote: post #7

Never allow yourself to be bullied or pressured into action. As a maintainer, the more a contributor or user nags, the less likely I am to oblige.

The issue here is the attackers will quickly move away from an individual attacking you to the group attacking you. The person writing the infected code will never be a jerk to you at all. You'll just suddenly see a huge portion of your mailing list move against you ever so slightly. We've complained about bots in social media for a long time, but how many people in open source discussions are shady manipulative enti…

These days you can even have these emails automatically taken in by an LLM and have the LLM argue with the maintainer for you, no humans needed!

Re: Timeline of the xz open source attack

#217

Post by dboreham »

Something I've wondered about wrt this debacle: presumably the smart part of xz was the compression algorithm. I'm guessing but that's probably less than 500 lines of code. The rest is plumbing to do with running the algorithm in a CLI utility, on various different OSes, on different architectures, as a library, and so on. All that stuff is at some level of abstraction the same for all things that do bulk processing on bytes of data. Therefore perhaps we should think about a scheme where the boilerplate-ish stuff is all in some framework that is well funded with people to ensure it doesn't have cutout maintainers injecting backdoors, and is re-used for hundreds of bulk-data-processing utilities; and the clever part would then be a few hundred lines of code that's easy to review, and actually probably never needs to change. Like...a separation of concerns.

Re: Timeline of the xz open source attack

#218

Post by agumonkey »

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…

What's gonna happen now ? a team of foss sec chaos monkey trying to run checks on a core set of libs ?

Re: Timeline of the xz open source attack

#219

Post by bckygldstn »

publius_0xf3 wrote: post #141
vb-8448 wrote: post #27

I wonder if netflix will make a movie from this story, if you read the timeline it really sounds like a well written thriller.

It does, but has there ever been a movie that successfully portrayed a compelling drama that takes place entirely on a computer monitor? It's hard to even imagine. It's why I think the novel is still relevant in our age because all the great stories that unfold on a screen can't be acted out on a sound stage.

Searching [0] gets you halfway there: its about a compelling drama which takes place mostly in real life, but is portrayed entirely on a computer monitor.

[0] https://en.wikipedia.org/wiki/Searching_(film)

Re: Timeline of the xz open source attack

#220

Post by 2OEH8eoCRo0 »

fizlebit wrote: post #209

What are the chances this is the first such attack, not just the first one discovered. Presumably every library or service running as root is open to attack and maybe also some running in userspace. The attack surface is massive. Time for better sandboxing? Once attackers get into the build systems of Debian and others is it game over?

I wouldn't be surprised if there are others but this specific one seems special. It was caught because on connection it does an extra decryption operation and I'd assume there is no way around this extra work. They'd have to re-architect this to not require that decryption.

I'm not a security expert though.

Post reply on HN