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

251–260 of 482 posts

Re: Timeline of the xz open source attack

#251

Post by klysm »

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.

until you have to integrate with the rest of the world sure

Re: Timeline of the xz open source attack

#252

Post by shawnz »

hyperman1 wrote: post #221
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.

Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left. There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverag…

When your programmatic build steps are isolated in plugins, then you can treat them like independent projects and apply your standard development practices like code review and unit tests to those plugins. Whereas when you stuff programmatic build steps into scripts that are bundled into existing projects, it's harder to make sure that your normal processes for assuring code quality get applied to those pieces of accessory code.

Re: Timeline of the xz open source attack

#253

Post by snerbles »

galleywest200 wrote: post #216
pixl97 wrote: post #184

Earlier quoted context omitted.

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!

Maintainers will need LLM sockpuppets of their own to automatically answer these automatic emails.

Re: Timeline of the xz open source attack

#254

Post by johnny22 »

npteljes wrote: post #159
tommiegannert wrote: post #29

Earlier quoted context omitted.

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 wonder if it would be possible to crowdsource FOSS mailing list moderation. I think this could be a genuine use of an AI: to go through all of the shit, and have it summarized in a fashion that the user wants: distant and objective, friendly, etc. It could provide an assessment on the general tone, aggregate the differently phrased requests, many things like that. Crowdsourcing would works best with the reddit / h…

A big problem is that people allow this sort of thing as part of the culture. I've followed the Fedora and PHP development mailing lists a few different times over the years ans this sort of thing was tolerated across the board. It doesn't matter if you crowdsource the moderation if nobody thinks the behavior is bad in the first place.

Trying to do something about it was called censorship.

Re: Timeline of the xz open source attack

#255

Post by maerF0x0 »

Hackbraten wrote: post #152
sebstefan wrote: post #90

Earlier quoted context omitted.

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?

On top of that: A newly-introduced security issue tends to have very limited exploitability, because it's valuable, not-yet well understood, and public exploits are yet to be developed. Compare to that a similar vulnerability in an older package: chances are that everything about it has been learned and is publicly known. Exploits have become a commodity and are now part of every offensive security distro on the plan…

> valuable, not-yet well understood, and public exploits

Except in the scenario that is this exact case: Supply chain attacks that are developed with the exploit in mind.

Re: Timeline of the xz open source attack

#256

Post by flockonus »

tomxor wrote: post #245
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 would be an improvement for sure... but this is not fundamentally a technical problem. Reading the timeline, the root cause is pure social engineering. The technical details could be swapped out with anything. Sure there are aspects unique to xz that were exploited such as the test directory full of binaries, but that's just because they happened to be the easiest target to implement their changes in an obfuscat…

Agreed it's mainly a social engineering problem, BUT also can be viewed as a technical problem, if a sufficiently advanced fuzzer could catch issues like this.

It could also be called an industry problem, where we rely on other's code without running proper checks. This seems to be an emerging realization, with services like socket.dev starting to emerge.

Re: Timeline of the xz open source attack

#257

Post by infamouscow »

smallmancontrov wrote: post #215
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.

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

Redis. Simple flat directory structure and a Makefile. If you need more, treat it as a sign from God you're doing something wrong.

Re: Timeline of the xz open source attack

#258

Post by maerF0x0 »

Two points I'd be interested in discussing.

1. It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way (and selected for their access). Why play the long game of let's find a lone package, w/ a tired maintainer, and then try to get in good with them vs. Let's survey all packages w/ a tired maintainer, and compromise a new entrant (ie bribe/beat them).

2. IMO this also is a failing on behalf of many government agencies. NSA, NIST, FBI all should, IMO spend less time compromising their own citizenry, and more time focusing on shoring up the security risks Americans face.

Re: Timeline of the xz open source attack

#259

Post by kibwen »

klysm wrote: post #251
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.

until you have to integrate with the rest of the world sure

Looking at the state of software security in the rest of the world, this may not be much of a disincentive. At some point we need to knuckle down and admit that times have changed, the context of tools built for the tech of the 80s is no longer applicable, and that we can do better. If that means rewriting the world from scratch, then I guess we better get started sooner rather than later.

Re: Timeline of the xz open source attack

#260

Post by carols10cents »

iso8859-1 wrote: post #146
mattxxx wrote: post #124

A service that measured "credibility" or "activity" of a username/email could be really useful here. At least, it would be a leading indicator that something _might_ be up. In particular the aside here about the email addresses are suspect: https://research.swtch.com/xz-timeline#jia_tan_becomes_maint... would be useful info for Lasse Collins before taking the pressure campaign seriously.

What about just using 'web of trust', for example with GPG? If the user's key is signed by people that met up with the actual person, it would be much harder to make fake identities.

What would prevent the sock puppet accounts from signing each others' keys?
Post reply on HN