Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

131–140 of 336 posts

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

#131

Post by 2OEH8eoCRo0 »

mapasj wrote: post #11

I’m guessing the original maintainer of xz handed responsibilities to Jia Tan without ever seeing him/her or at least sharing a phone call. Is that common to only communicate only through email/github? I guess some maintainers of open source projects will be more cautious after this story.

Our goodwill is being used against us.

Suppose you have a chat with them and see that they're Chinese. What are your next actions? If you exclude them then that's racist right?

I don't have answers

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

#132

Post by redserk »

gunapologist99 wrote: post #118
redserk wrote: 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.

> 2) Simply meeting IRL is a terrible proxy for credibility. Disagree; trust your intuition, but you can never do that if you never meet IRL. Also, it's not racist or xenophobic to recognize that some countries exercise nearly complete control over their citizens (and sometimes indirectly over non-citizens), and that those people could be putting themselves at extreme personal risk by disobeying those dictates (assum…

> WRT 2, no, it's not.

> Trust your intuition, but you can never do that if you never meet IRL.

I'm sure Edward Snowden also met up with colleagues in the office at least a few times. May have even passed a security clearance.

> Also, it's not racist or xenophobic to recognize that some countries exercise nearly complete control over their citizens (and sometimes indirectly over non-citizens), and that those people could be putting themselves at extreme personal risk by disobeying those dictates, if they even disagreed with them.

Hold up, where did I make this claim about national origin/external pressure?

I'm only suggesting if you have pets, a kid, or a project at work, conferences take a non-zero amount of time to plan to attend.

Plus, what conference options even exist if you're finding other people for the xz library? Searching for #CompressionConf2024 isn't turning up much.

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

#133

Post by SAI_Peregrinus »

dcow wrote: post #115
EdiX wrote: 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…

Not agreeing or disagreeing, just curious how you draw conclusion (4)? This attack has nothing to do with systemd or its ecosystem etc.

This attack used the fact that several distros patch OpenSSH to link to libsystemd for notifications. Libsystemd links liblzma, and the backdoor checks if it's been linked into OpenSSH's sshd process to run. Without distro maintainers linking libsystemd, xz wouldn't have been a useful target for attacking OpenSSH.

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

#134

Post by lenerdenator »

redserk wrote: post #109
MiscIdeaMaker99 wrote: post #96

Earlier quoted context omitted.

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.

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

It's not the only thing, but it is something.

There's a lot of social engineering that went into the xz backdoor[0]. This started years ago; Jia Tan was posting in projects and suddenly someone appeared to pressure projects to accept their code. Who's Jia Tan? Who's Jigar Kumar, the person who is pressuring others to accept patches from Jia Tan? We don't know. Probably some person or group sponsored by a state APT, but we don't know for sure, because they're currently just text on a screen.

Having this person or group of people have to continually commit to the bit of publicly-known open-source maintainer who attends conferences, has an actual face, and is on security camera footage at multiple hotels and airports is far, far harder than just talking a vulnerable person into allowing maintainer access on a repository. Making them show up to different places a few times adds a layer of identity. Otherwise these "skilled eyes" could be anyone with a wide variety of motivations.

[0]https://boehs.org/node/everything-i-know-about-the-xz-backdo...

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

#135

Post by jasode »

aerhardt wrote: post #106
Denvercoder9 wrote: post #93

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…

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.

>I’m not in OSS but I hire technical people remotely, [...] interviews on Zoom.

Different situations with different incentives and psychology:

- potential to receive money : job candidates are willing to get on Zoom calls or meet in person because they want a paycheck.

- no money involved & volunteer for free : potential open source contributors are not interested in getting on Zoom calls for $0 pay.

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

#136

Post by xyst »

What can be learned here and improve?

- systemd and libsystemd is an absolute mess. What are the alternatives at this point?

- what processes can be improved for Linux distributions to catch malicious actors trying to push back doors into the ecosystem?

- is there a dependency graph that would show how many programs use a specific utility library? Might aid in finding other possible attempts to backdoor

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

#137

Post by kqr »

jbergknoff wrote: post #76
heresie-dabord wrote: post #45

Earlier quoted context omitted.

More personal observations: 8. Consumers are naive, yes. But the software industry itself is naive about the security threat. 9. The social exploit is part of the code exploit. 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated. FOSS needs material support from industry. A MSFT engineer caught this exploit, but it still was released to G.A. in Fedora 41, openSUSE, and Kali . 11. The…

> 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated. One thing that could help with this is if somebody points an LLM at all these foundational repositories, prompted with "does this code change introduce any security issues?".

I found the black hat!

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

#138

Post by aerhardt »

Denvercoder9 wrote: post #114
aerhardt wrote: post #106

Earlier quoted context omitted.

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.

Interviewing is a different situation though, because you start having essentially no relationship with the interviewee, and you haven't seen their work. OSS projects don't just add everyone that asks as a co-maintainer. Usually it's someone that has contributed to the project for a while already, and through that has shown they understand the code, are capable of improving it, and can make sensible decisions about t…

Yea, I get that, from what I see in the details of this case the contributor was very competent. What I'm questioning here is whether in OSS projects there is enough face-to-face communication, probing about values, etc.

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

#139

Post by xorcist »

kuschku wrote: post #61
tomohawk wrote: post #27

Earlier quoted context omitted.

libsystemd is too juicy of a target, especially with the code reuse that does not appear to take into account these attack vectors. Perhaps any reuse of libraries in sensitive areas like libsystemd should require a separate copy and more rigorous review? This would allow things like libxv to be 'reused', but the 'safe' versions would require a separate codebase that gets audited updates from the mainline.

libsystemd had already removed the lzma dependencies last week, before the backdoor became public, to reduce external dependencies.

No they did not. The dependency is still there, it's just being lazy loaded.

This would be prevented this particular exploit, which would have needed to take another approach, but at the price of making dependencies invisible and hard to debug. You could no longer have found vulnerable systems by way of ldd.

The only solution for the attack surface of systemd is to make the individual components more loosely coupled. There is no reason the same library is responsible for readiness reporting and reading logs.

One could even argue that none of those functions have anything to do with the job of init. Readiness can break in a number of ways, robustness is built on health checks.

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

#140

Post by mjw1007 »

EdiX wrote: post #84
rcxdude wrote: post #56

Earlier quoted context omitted.

I would more just say autogenerated artifacts should just be autogenerated by the build. Committing them doesn't really solve the problem. This is pretty much just a historical hangover in autotools where it targeted building on platforms where autotools wasn't installed, but it's not really a particularly relevant use-case anymore. (I do agree in general that autotools is bad. Especially on projects where a simple m…

> I would more just say autogenerated artifacts should just be autogenerated by the build. There are practical and philosophical problems with this. From the practical point of view you generally want to make contributing (or even just building) your stuff as low friction as possible and having extra manual build steps (install tools X at version X1.X2.X3, Y at version Y1.Y2 and Z at version Z1.Z2rc2) isn't low frict…

The fact that the protocol has changed over time is itself a problem.

It isn't reasonable to expect everyone maintaining a daemon to keep track of additions.

Post reply on HN