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

391–400 of 482 posts

Re: Timeline of the xz open source attack

#391

Post by pixl97 »

2devnull wrote: post #388
pixl97 wrote: post #189

Earlier quoted context omitted.

> Is there a photo of the person? Does that even matter these days? Especially if we're talking nation state level stuff convincing histories are not hard to create to deflect casual observers. >Be more paranoid. Most people in OSS just want to write some code to do something, not defend the world against evil.

“Does it even matter?” Yes, it would have prevented this attack. It isn’t totally sufficient but it’s quick and easy and would have prevented this attack. “Most people don’t want …” I get it. I think the issue is that pushing junk code from malicious contributors into your project causes more hassle in the long run. If you just want to code and make stuff work, you should probably be careful who you pull from. It’s n…

"Sorry, we had to kill open source software because bad people exist" -Microsoft laughing all the way to the bank.

The more paranoid walls you put up the more actual contributors getting into the movement say "eh, screw this, who wants to code anyway".

This isn't just a problems with OSS, this is a fundamental issue the internet as a whole is experiencing and no one has good answers that don't have terrible trade offs of their own.

Re: Timeline of the xz open source attack

#392

Post by pixl97 »

cryptonector wrote: post #371
pixl97 wrote: post #187

Earlier quoted context omitted.

>It's either in source form and reproducable or it's not there. Wanna know how I know you haven't read into the discussion much? There are a whole lot of binary test cases in software. Especially when you're dealing with things like file formats and test cases that should specifically fail on bad data of particular types.

GP is talking about executable blobs (drivers) more than anything. Yes, binary protocols will lead to binary test blobs, so what.

The attack was embedded in a binary test blob, or did you just not happen to read anything about the xy attack?

Re: Timeline of the xz open source attack

#393

Post by mardifoufs »

Dalewyn wrote: post #284
davedx wrote: post #238

Earlier quoted context omitted.

Nonsensical argument. JavaScript and TypeScript projects are developed with patches of the original source not some compressed artefact. Take your trolling elsewhere

[flagged]

Javascript is almost always executed in sandboxed, unprivileged environments. The issue here is that this type of obfuscation is easy to add in core os libraries. The JavaScript ecosystem, for all the hate that it gets, makes it super easy to sandbox any running code.

It doesn't matter if it's minified or obfuscated because you basically have to run unknown, untrusted code everywhere while browsing the web with JavaScript turned on. So the ecosystem and tooling is extremely resilient to most forms of malicious attacks no matter how minified or obfuscated the js you're running is. The complete opposite is true for bash and shell scripting in general

Re: Timeline of the xz open source attack

#394

Post by kibwen »

hyperman1 wrote: post #262
kibwen wrote: post #224

Earlier quoted context omitted.

> Findbugs, code coverage, source code generation,... For the purpose of this conversation we mostly just care about the use case of someone grabbing the code and wanting to use it in their own project. For this use case, dev tools like findbugs and code coverage can be ignored, so it would suffice to have a version of the build system with plugins completely disabled. Code generation is the thornier one, and we can…

The xz debacle happened partiallybecause the generated autoconf code was provided. Checking in generated code is not that much better. It's a bit more visible, but not much people will spend their limited time to validate it, as it's not worth it for generated code. xz also had checked in inscrutable test files, and nobody could know it was encrypted malware. I'm not a fan of generated code. It tends to cause misery,…

> The xz debacle happened partiallybecause the generated autoconf code was provided.

The code was only provided in a roundabout way that was deliberately done to evade manual inspection, so that's not a failure of checking in generated code, that's a failure of actually building a binary from the artifacts that we expect it to be built from. Suffice to say, cutting out the Turing-complete crap from our build systems is only one of many things that we need to fix.

Re: Timeline of the xz open source attack

#395

Post by kibwen »

duped wrote: post #360
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 would that accomplish? It certainly wouldn't have stopped this attack. > 99.9% of all projects have the capability to be built with trivial declarative rulesets. Only if you forbid bootstrapping, which all projects ultimately rely on at some point in their supply chain.

> What would that accomplish? It certainly wouldn't have stopped this attack.

We could write an entire PhD thesis on the number of dire technical failings that would need to be addressed to stop this attack, so while this alone wouldn't have stopped it, it would have required the actor to come up with another vector of code injection which would have been easier to find.

> Only if you forbid bootstrapping

Codebases that bootstrap are the 0.1%. Those can be built via `bash build.sh` rather than deceptively hiding a Turing-complete environment behind a declarative one. Even if you need to have these in your trusted computing base somewhere, we can focus auditing resources there, especially once we've reduced the amount of auditing that we need to do on the other 99.9% of codebases now that we've systematically limited the build-time shenanigans that they can get up to.

Re: Timeline of the xz open source attack

#396

Post by cryptonector »

pixl97 wrote: post #392
cryptonector wrote: post #371

Earlier quoted context omitted.

GP is talking about executable blobs (drivers) more than anything. Yes, binary protocols will lead to binary test blobs, so what.

The attack was embedded in a binary test blob, or did you just not happen to read anything about the xy attack?

You can't avoid having to have binary blobs of data. And again, GP was talking about closed-source drivers, not specifically the xz attack.

Re: Timeline of the xz open source attack

#397

Post by MySweetHubert »

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.

The 2017 WannaCry ransomware attack would be a good counter example, the virus spread even though it was already fixed in an update from MS a bit more than a month before.

Re: Timeline of the xz open source attack

#398

Post by sfjailbird »

gawa wrote: post #47

Excellent summary of the events, with all the links in one place. This is the perfect resource for anyone who want to catch up, and also to learn about how such things (especially social engineering) unfold in the wild, out in the open. One thing that could be added, for the sake of completeness: in the part "Attack begins", toward the end, when they are pushing for updating xz in the major distros, Ubuntu and Debian…

It would be intetesting if Lasse Collin published his off-list interactions with 'Jia Tan' and any of the other pseudonyms, to get an even better angle on the social engineering parts. Apparently a large part of the campaign was via private channels to Lasse.

Re: Timeline of the xz open source attack

#399

Post by r00fus »

goku12 wrote: post #49
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.

There is a good chance that everyone in that thread except the original maintainer is in on the act. It's likely that all those accounts are managed by a single person or group. Targeting just one account for rudeness isn't going to help, if that's true.

The act relies on there being an extreme reluctance to ban. Once the banhammer has been used, the act kind of falls apart. Of course, difference pressure campaigns can then be brought to bear.

We live in an adversarial environment, time to stop playing naively nice. Ideally it isn't the maintainer that has to do all this work.

Re: Timeline of the xz open source attack

#400

Post by larntz »

sfjailbird wrote: post #398
gawa wrote: post #47

Excellent summary of the events, with all the links in one place. This is the perfect resource for anyone who want to catch up, and also to learn about how such things (especially social engineering) unfold in the wild, out in the open. One thing that could be added, for the sake of completeness: in the part "Attack begins", toward the end, when they are pushing for updating xz in the major distros, Ubuntu and Debian…

It would be intetesting if Lasse Collin published his off-list interactions with 'Jia Tan' and any of the other pseudonyms, to get an even better angle on the social engineering parts. Apparently a large part of the campaign was via private channels to Lasse.

I was wondering if that would be released also. I hope so but wouldn't blame them if they decide not to.
Post reply on HN