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

371–380 of 482 posts

Re: Timeline of the xz open source attack

#371

Post by cryptonector »

pixl97 wrote: post #187
jhoechtl wrote: post #16

> merges hidden backdoor binary code well hidden inside some binary test input files. [...] Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves. So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware. It's either in source form and reproducable or it's not there.

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

Re: Timeline of the xz open source attack

#372

Post by mzs »

ok123456 wrote: post #236
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.

People have been bullied out of 'nice' communities. See the 'Actix' debacle in Rust.

That was mostly redditors though. Reddit is not a nice community.

Re: Timeline of the xz open source attack

#374

Post by Hackbraten »

testplzignore wrote: post #367
sloowm wrote: post #138

Earlier quoted context omitted.

Another point relevant on the timeline is when downstream starts using binaries instead of source. I think people are flying past that important piece of the hack. Without that this would not have been possible. If there is a trusted source in the middle building the binaries instead of the single maintainer and the hacker this attack becomes extremely hard to slip by people.

I'm not familiar with how distros get the source code for upstream dependencies. I'm trying to understand what Andres meant when he said this: > One portion of the backdoor is solely in the distributed tarballs Is it that the tarball created and signed by Jia had the backdoor, but this backdoor wasn't present in the repo on github? And the Debian (or any distro) maintainers use the source code from tarball without co…

Exactly.

The threat actor had signed and uploaded the compromised source tarball to GitHub as a release artifact. They then applied for an NMU (non-maintainer upload) with Debian, which got accepted, and that's how the tarball ended up on Debian's infrastructure.

Re: Timeline of the xz open source attack

#375

Post by riston »

xz most likely wasn't the only library that was targeted, there could be other similar projects as well which we haven't discovered yet. From the timeline you can see the social engineering part was quite big part.

Just thinking out loud, would it possible to go over with LLM and analyse existing OSS mailing lists and issues to classify such sentiment from the users?

Re: Timeline of the xz open source attack

#376

Post by Tainnor »

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.

I don't want to excuse rudeness or a sense of entitlement. But I think we can still understand where it comes from. A lot of these people probably work on crappy codebases where "let's just add a random dependency without any vetting" was the norm, they might have to deal with production issues etc. There's probably a systemic issue behind it, that our industry relies too much on unpaid labour and is usually not willing to contribute back.[0]

[0] Funnily enough, just a week or two ago, I fixed an issue in an OS project that we introduced at work. It was an easy frontend fix even for someone like me who doesn't do frontend and barely knows how to spell Vue. And more importantly, in the issue description somebody already wrote exactly what causes the bug and what would need to change - the only thing left was finding the place where to make the (one-line) change. Somehow that issue had been open for 2 years but nobody of the several people who complained (nor the maintainer) had bothered to fix it. After I made a PR, it was merged within a day.

Re: Timeline of the xz open source attack

#377

Post by RyanCavanaugh »

publius_0xf3 wrote: post #275
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.

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…

There are plenty of hyper-competent technical people in the field who are also kind and patient. Being smart doesn't turn someone into a jerk.

Re: Timeline of the xz open source attack

#378

Post by Tainnor »

publius_0xf3 wrote: post #275
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.

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.

Re: Timeline of the xz open source attack

#379

Post by nmz »

Longlius wrote: post #240
jbdigriz990 wrote: post #225

Joe Cooper's take on pressuring project maintainers: https://forum.virtualmin.com/t/dont-panic-ssh-exploit-in-ble... somewhat ironic, but I'd say effective.

I don't even think it's necessarily moderation so much as maintaining these high-traffic projects is now akin to a full-time job minus the pay. At a certain point, companies need to step up and provide funding or engineering work or they should just keep expecting to get owned.

Why would they when they can just... not?

Re: Timeline of the xz open source attack

#380

Post by shawnz »

dotancohen wrote: post #334
shawnz wrote: post #252

Earlier quoted context omitted.

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

My standard development practices like code review and unit tests do not scale to review and test every dependency of every dependency of my projects. Even at company-wide scale.

I'm not saying that. I'm just saying that improved ability to apply such development practices is one benefit of using a plugin-style architecture for isolating the programmatic steps of your build pipeline. It's not perfect but in many ways it's still a significant improvement upon just allowing arbitrary code right in the pipeline definition.
Post reply on HN