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

431–440 of 482 posts

Re: Timeline of the xz open source attack

#431

Post by vb-8448 »

in3d wrote: post #79
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’s not compelling enough unless we find out who was behind it, which is probably unlikely.

Well, the identity of who's behind it can be left to the imagination of the authors.

I think it's reasonable to think that behind this attack there is a well organized intelligence agency of a big country, so the author can choose the one that they likes more.

Or, even better, delay the issue to the season 2 :D

Re: Timeline of the xz open source attack

#432

Post by vb-8448 »

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.

I liked "How to Sell Drugs Online (Fast)", first season.

Generally speaking, you can use the xz story as a background for every type of movie set in the present, an eg.: think about the God's Eye story from the Fast & Furious series. Theoretically, the xz rce can give you more or less the same power God's Eys gives you in the film.

Re: Timeline of the xz open source attack

#433

Post by darkwater »

cesarb wrote: post #123
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.

> Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Another example of this was log4j: if you were still using the old 1.x log4j versions, you wouldn't have been vulnerable to the log4shell vulnerability, since it was introduced early in the 2.x series. The old 1.x log4j versions had other known vulnerabilities, but only if…

> "so that when another vulnerability happens, upgrading to a fixed version (which is assumed to be based on the latest release) will be easy".

Isn't this still true, generally speaking? How many servers are daily compromised due to out of date, exploitable versions of software versus XZ-like sophisticated attack?

Re: Timeline of the xz open source attack

#434

Post by GreenWatermelon »

Tainnor wrote: post #378
publius_0xf3 wrote: post #275

Earlier quoted context omitted.

I want to caution against taking a good thing too far. There's a certain kind of talented person who is all too conscious of their abilities and is arrogant, irascible, and demanding as a result. Linus Torvalds, Steve Jobs, Casey Muratori come to mind. Much as we might want these characters to be kinder, their irascibility is inseparable from their more admirable qualities. Sometimes good things, even the best things…

Linus Torvalds is apparently trying to do better (although I haven't followed up with the progress), but more importantly, while he might be (have been) unnecessarily rude and aggressive, he's not entitled (as far as I know). I don't think he would jump into an issue tracker of some project he doesn't maintain and demand that certain changes be made.

After watching a recent talk with Linus Torvalds[0], it seems that he's become more soft spoken.

[0] clip about the Nvidia "incident" https://youtu.be/wvQ0N56pW74

Re: Timeline of the xz open source attack

#435

Post by fl7305 »

koito17 wrote: post #211
kibwen wrote: post #197

Earlier quoted context omitted.

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 r…

> there are plenty of legitimate reasons that program could fail to compile

It's worse than that, these small C files are required to fail unless the target build environment meets some specific requirements.

Re: Timeline of the xz open source attack

#437

Post by jvanderbot »

none_to_remain wrote: post #270
jvanderbot wrote: post #54

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

Avoid compromise with one simple trick: surrender to the attackers

I don't understand how "Accept public money to work full time on key software" is surrender, but I think everyone misunderstood what I said, which usually means I didn't say what I meant.

Re: Timeline of the xz open source attack

#438

Post by ta1243 »

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 the problem - we have record numbers of computer programmers, having increased exponentially from the 90s, however very few of them want to work just for fun on some library buried deep in the system, most are just out for a quick buck.

Look at the number of people who make meaningful commits to ffmpeg vs the number of people that wrap it in some UI and somehow persuade thousands of people that their solution is amazing, and ffmpeg is a sexy project.

Re: Timeline of the xz open source attack

#439

Post by noctune »

comex wrote: post #286
wongarsu wrote: post #241

Earlier quoted context omitted.

Most of these could still be covered with IO limited to the project files though. There is a sizable movement in the Rust ecosystem to move all build-time scripts and procedural macros to (be combined to) WASM. This allows you to write turing-complete performant code to cover all use-cases people can reasonably think of, while also allowing trivially easy sandboxing. It's not perfect, for example some build scripts d…

But the xz backdoor didn’t involve a build script that tried to compromise the machine the build was running on. It involved a build script that compromised the code being built. Sandboxing the build script wouldn’t have helped much if at all. Depending on the implementation, it might have prevented it from overwriting .o files that were already compiled, maybe. But there would still be all sorts of shenanigans it co…

The xz backdoor did hide the payload in test data though. Proper sandboxing could have meant that eg. building the binary wouldn't have access to test data.
Post reply on HN