Live data from Hacker News

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

101–110 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#101

Earlier quoted context omitted.

I think you could interpret this as "you need to know, personally, the party you're handing this off to, and make reasonable judgments as to whether or not they could be easily compromised by bad actors". Like, meeting someone at several dev conferences should be a requirement at the very least.

> Like, meeting someone at several dev conferences should be a requirement at the very least. This is utterly and completely unfeasible. Most open source maintainers, especially those that are struggling and are pressured to hand-off maintenance, don't have the time, means and will to travel to meet up with prospective co-maintainers, not just once but multiple times. In practice it would just result in projects gett…

Really, it starts before things get bad. This thing where - in the famous XKCD example - a single guy is thanklessly maintaining a project for 20 years in Nebraska needs to stop. Software libraries like these are no longer a one-person job. They can't be for the bus factor alone. Major projects like Linux distros or bigger foundations like Apache or Mozilla need to start harping on people hard to contribute to important libraries. We'll get to whatever the buzzword of the day is once we do the important work first.

Find a way to make it happen. Sorry, "I just can't" isn't going to cut it after this.

Re: What we know about the xz Utils backdoor that almost infected the world

#102
post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

[flagged]

Re: What we know about the xz Utils backdoor that almost infected the world

#103
What I haven't seen discussed much is the linking mechanism that allowed the lib to hook into RSA_public_decrypt. Plenty of talk about what could or could not be achieved by even more process separation and the like, but little about that function call redirect. Could it be possible to establish a way to link critical components like the code for incoming ssh with libraries in some tiered trust way? "I trust you when and where I call you, but I won't allow you to introduce yourself to other call sites"?

This would surely fall into the category of "there would be ways around it, so why bother?" that triggers a "by obscurity" reflex in many, but I'd consider it reduced attack surface.

Re: What we know about the xz Utils backdoor that almost infected the world

#104
post #51

Earlier quoted context omitted.

I am also curious, and if something like asan would also have found it? It seems social engineering was used to get MS to stop fuzzing the library for malicious code, so if the malicious party expected the valgrind behavior they might have removed it as well.

Which to me is a very carefully orchestrated thing. You don't just spend 2 years of your life doing that. No loner would pre-plan this to such an extent and create sockpuppet accounts for all this.

That's because you're a normal, well adjusted person.

Consider TempleOS[1] which was created by a programmer having a series of manic episodes which he believed was God's instruction to create 640x480 pixels of perfection.

He spent the rest of his life on this.

People vastly underestimate the tenacity of individual fixated people: so much so that in the physical world victims usually feel isolated by their peers who just don't believe the degree of effort they stalker will actually go to.

[1] https://en.m.wikipedia.org/wiki/TempleOS

Re: What we know about the xz Utils backdoor that almost infected the world

#105

Why do they say "almost" infected the world? At least 3 quite popular Linux distributions (arch, gentoo, and opensuse tumbleweed) ended up shipping the backdoor _for weeks_ , and it was most definitely working in at least tumbleweed. For weeks! A backdoored ssh! Hardly "almost".

I heard that sshd in arc doesn’t link to xz

Re: What we know about the xz Utils backdoor that almost infected the world

#106

Earlier quoted context omitted.

I think you could interpret this as "you need to know, personally, the party you're handing this off to, and make reasonable judgments as to whether or not they could be easily compromised by bad actors". Like, meeting someone at several dev conferences should be a requirement at the very least.

> Like, meeting someone at several dev conferences should be a requirement at the very least. This is utterly and completely unfeasible. Most open source maintainers, especially those that are struggling and are pressured to hand-off maintenance, don't have the time, means and will to travel to meet up with prospective co-maintainers, not just once but multiple times. In practice it would just result in projects gett…

You could probably get about 80% of the job done with just 20% of the work. I’m not in OSS but I hire technical people remotely, and I know many people that do. Some consultant friends have caught blatant scams within the first couple of rounds of interviews on Zoom.

Re: What we know about the xz Utils backdoor that almost infected the world

#107

Why do they say "almost" infected the world? At least 3 quite popular Linux distributions (arch, gentoo, and opensuse tumbleweed) ended up shipping the backdoor _for weeks_ , and it was most definitely working in at least tumbleweed. For weeks! A backdoored ssh! Hardly "almost".

My guess is that most Linux boxes that run sshd use an LTS distro, not one with rolling release. But I don’t know how to get any data on this.

Re: What we know about the xz Utils backdoor that almost infected the world

#108
post #47

Earlier quoted context omitted.

They did communicate off list and non publicly, that's as much as we know at the moment. As an open source developer he might have received donations too from the adversary - it's reasonably common for devs to get donations to "say thanks". He might have had voice chats with them, who knows. The emails might be with LEO at the moment but I think its in the public interest for all communications to be released.

It is unfortunate that Lasse Collin has been silent about what he knows about him

For his own personal safety, he might not want to get on the bad side of whatever (powerful) actor was behind this exploit.

Re: What we know about the xz Utils backdoor that almost infected the world

#109
post #92

Earlier quoted context omitted.

1) Not everyone (current and potential future maintainers) has the time to go to dev conferences. 2) Simply meeting IRL is a terrible proxy for credibility.

What would be better?

It's naive to believe that any form of physical presence means someone isn't going to do something nefarious in the eyes of the project.

This problem can only be solved by more skilled eyes on the projects that we rely on. How do we get there? shrug.gif.

Anything less is trying to find a cheap and ineffective shortcut in this trust model.

Re: What we know about the xz Utils backdoor that almost infected the world

#110

Earlier quoted context omitted.

> Like, meeting someone at several dev conferences should be a requirement at the very least. This is utterly and completely unfeasible. Most open source maintainers, especially those that are struggling and are pressured to hand-off maintenance, don't have the time, means and will to travel to meet up with prospective co-maintainers, not just once but multiple times. In practice it would just result in projects gett…

Really, it starts before things get bad. This thing where - in the famous XKCD example - a single guy is thanklessly maintaining a project for 20 years in Nebraska needs to stop. Software libraries like these are no longer a one-person job. They can't be for the bus factor alone. Major projects like Linux distros or bigger foundations like Apache or Mozilla need to start harping on people hard to contribute to import…

I agree we need to stop depending on the 20-year hobby project of the guy in Nebraska, but adding barriers (which requiring travel and in-person meetings is) to sharing the load is not the solution. What these projects need is the necessary resources (mostly money) for multiple people to work on it professionally.
Post reply on HN