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

161–170 of 336 posts

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

#161

Post by growse »

binkHN wrote: post #59
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…

> 4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencies and most programs use a tiny fraction of it. Encouraging every service to depend on it for initialization notifications is insane. I couldn't agree more. Coming from the BSD world, systemd is a shock to the system; it's monstrous and has tendrils everywhere.

If you actually come from BSD, you'd hopefully recognize a set of different utilities combined to form a holistic system released under a single name. It's not a new idea.

Besides, the gpp is incorrect: systemd dependencies are not needed for initialisation notifications.

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

#162

Post by samtheprogram »

Denvercoder9 wrote: post #87
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".

Arch, Gentoo and openSUSE Tumbleweed are hardly the world.

Arch and Gentoo were also not supported, although the code shipped, because the exploit explicitly checked for RPM- and deb-packaged distros.

Suse is RPM based, but don’t remember whether the check was for the utilities or another method — Suse uses zypper for package management, as opposed to yum/dnf on the far more popular RedHat-based distros, so it depends how the exploit checked.

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

#163

Post by nebulous1 »

CommitSyn wrote: post #142
chpatrick wrote: post #72

Earlier quoted context omitted.

I mean if I was working for a state and had the job of compromising xz that's exactly what I would do.

> Either way, it's your preference and I will follow your lead. Jia Tan > It's out of the scope for this patch, but it is something worth considering. Just trying to do my part as a helper elf! Jia Tan Sounds like someone pulling the strings and using the "it's your idea, I'm just following!" strategy. My hunch from reading over all the language used is that this person spent a good deal of time in America and has a…

I read that as "us" being the xz dev team.

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

#164

Post by growse »

dboreham wrote: post #154
Tuna-Fish wrote: post #34

Earlier quoted context omitted.

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.

The notification can be done by sending some data to $NOTIFY_SOCKET. That's all sd_notify does.

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

#165

Post by sokoloff »

Nullabillity wrote: post #146
simiones wrote: post #86

Earlier quoted context omitted.

I think the point is that all of the code which will get compiled to produce the final binary should be in the repo, and so any generated code that affects the final binary should be in the repo. The use of autotools or other similar tools, ones that are supposed to generate code on the fly on the final user's machine, make this requirement essentially impossible.

Your compiler also falls under that bucket, though.

Reference the old Ken Thompson compiler hack to provide a backdoor for Unix logins: https://wiki.c2.com/?TheKenThompsonHack

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

#167

Post by markus_zhang »

I have said this before and I'm saying it again: Open source maintainers' first responsibility is to take care of him/herself, mentally and financially. You guys should proactively seek payments from whoever uses your work commercially, and if the $$ is not good enough, you are on your own to continue do this voluntarily.

If you keep the front door open, eventually thieves will come and steal your stuffs. By the same principal, if you do not rigorously request payments and donations, you should expect people to take advantage of you.

From this perspective, Tan, whoever he/she is, actually did you a great service -- those big companies got a rude awakening and are scrambling to double check whether they are impacted, over weekend. It is a pity that this did NOT get into a stable release -- I know it's very rude to say so, but let me be honest here -- it will be a greater help to all open source maintainers if this actually gets into a stable release and fuck over as many people as possible.

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

#168

Post by benlivengood »

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…

9. We should move toward formal verification for the trusted core of systems (compilers, kernel, drivers, networking, systemd/rc, and access control).

With regard to 1, there are some other practical steps to take. Use deterministic builds and isolate the compilation and linking steps from testing. Every build should emit the hashes of the artifacts it produces and the build system should durably sign them along with the checksum of the git commit it was built from. If there need to be more transformations of the artifacts (packaging, etc.) it should happen as a separate deterministic build. Tests should run on a different machine than the one producing the signed build artifacts. Dropping privileges with SECCOMP for tests might be enough but it's also unlikely to be practical for existing tests that expect a normal environment.

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

#169

Post by teddyh »

SAI_Peregrinus wrote: post #153
glandium wrote: post #6

Earlier quoted context omitted.

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

IIRC, they did report the bug, and it was rejected.

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

#170

Post by markus_zhang »

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 hope Open Source maintainers and the big companies get the message -- they need to change the financial outlook of open source maintaining.
Post reply on HN