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

151–160 of 336 posts

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

#151

Post by lenerdenator »

redserk wrote: post #132
gunapologist99 wrote: post #118

Earlier quoted context omitted.

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

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

And that's why we know who Edward Snowden is. That's more than we can say about Jia Tan.

Say what you will about what he did and why, it is going to be very, very hard for someone to explain to a contract's security auditor why, in the year 2024, a commit from an account known to belong to Edward Snowden is in the source code of security-critical software.

And that's what FOSS-based companies and orgs need to start doing after this. If I'm working for Debian/Mozilla/Apache/wherever, I'm going to start asking project maintainers more about who they are. "Hey man, we've got an all-expenses-paid trip to one of the major conferences this year, which one can we put you down for?" needs to come out of someone's mouth at some point, and excluding some very good reasons and evidence for why they can't appear at one of these events in-person (think health or long-term family obligation reasons, confirmed by multiple people who know the maintainer), they need to be at one or more meetings within a reasonable amount of time. Randomly-timed remote video meetings could work in a pinch.

If they can't after a couple of years, then these projects need to inform the maintainers that they'll be forking the project and putting it under a maintainer who can be verified as a living, breathing, single person.

Repeat until there's at least some idea of who's working on most of these projects that make up critical systems that society is built upon.

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

#152

Post by withinboredom »

stefanka wrote: post #105
AshamedCaptain wrote: post #69

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

the link to xz was in systemd that then loaded sshd with the exploit in the shared libraries.

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

#153

Post by SAI_Peregrinus »

glandium wrote: post #6
farmdve wrote: post #3

Earlier quoted context omitted.

And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project. It seems it is common practice for people to ignore these errors.

Do you remember the Debian openssl flaw? Okay, it's almost 20 years old now, so you may have forgotten, or you could be too young, I don't know. But it was caused by someone attempting to fix an oddity found by valgrind. https://blogs.fsfe.org/tonnerre/archives/24

There was an upstream OpenSSL bug there: they depended on reading from uninitialized memory to add entropy and thus increase startup speed of their RNG. But reading from uninitialized memory is undefined behavior, it's not guaranteed to add any entropy and should always be treated as a security bug. The Debian maintainers tried to fix the bug, but screwed up the fix. They should have reported the bug upstream, not just made their own fork.

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

#154

Post by dboreham »

Tuna-Fish wrote: post #34
phkahler wrote: post #15

Why does SSH use xz? Should it? Is it really that important?

It does not. OpenSSH pulled in libsystemd to provide startup notification. Libsystemd pulled in liblzma. No code from liblzma normally ends up in OpenSSH. But because it is built as a dependency for libsystemd, it's build scripts are ran in the same environment as libsystemd, and OpenSSH. The attack payload was hidden as an obfuscated binary blob in the liblzma tests directory, masqueraded as a compression test case.…

> pulled in libsystemd to provide startup notification

This seems sort of fine (although...why can't said notification be done by writing simple text to a pipe/file/socket?), but the library shouldn't be some kitchen-sink thing that links to the universe of attack surface.

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

#155

Post by Karellen »

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…

> 1a. As a consequence of (1) autogenerated artifacts should always be committed.

Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be?

> 4. Libsystemd is a problem for the ecosystem.

libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bunch of other helper libraries. What if the attack had come via one of those 2-or-3-dependencies-removed libraries? libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem?

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

#157

Post by growse »

withinboredom wrote: post #152
stefanka wrote: post #105

Earlier quoted context omitted.

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

the link to xz was in systemd that then loaded sshd with the exploit in the shared libraries.

Only for distros that took a specific openssh patch (not merged in upstream openssh). Arch didn't afaik.

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

#158

Post by Symmetry »

yosito wrote: post #4

Are we ever going to figure out who Jia Tan is?

I've been going through Wikiepdia's list of countries by GDP and trying to think about what the poorest country is that could pull it off in the normal course of business, and the poorest country that could pull this off if the leader decided it was important and was willing to push a little. I think there are at least a hundred countries in the later category.

https://en.wikipedia.org/wiki/List_of_countries_by_GDP_(nomi...

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

#159

Post by [deleted] »

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.

[deleted]

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

#160

Post by SAI_Peregrinus »

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…

I'd add a 9: performance differences can indicate code differences. Without the 0.5s startup delay being noticed the backdoor wouldn't have been found. It would be much easier to backdoor low-performance software that takes several seconds to start than something that starts nearly instantly.
Post reply on HN