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

81–90 of 336 posts

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

#81

Post by Denvercoder9 »

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…

> 8. This sucks to say, but code reviews and handing off maintainership, at the moment, need to take into account geopolitical considerations.

That won't help. There's no evidence that Jia Tan is a real name, or even a real person for that matter. If projects stop accepting contributions from asian-sounding names, the next attack will just use Richard Jones as a name.

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

#82

Post by edward28 »

mi_lk wrote: post #35
otherme123 wrote: post #32

Earlier quoted context omitted.

I guess the blame is on the people who decide to depend on a very small (by team size at least) project: https://xkcd.com/2347/ . While having plenty of safer alternatives. Lets suppose I create a personal and hobby project. Suddenly RedHat, Debian, Amazon, Google... you name it, decide to put my project as a fundamental dependency of their toolchain, without giving me at least some support in the form of trustable d…

> While having plenty of safer alternatives What are xz's safer alternatives? And how do you make sure of that?

Zstd because Facebook is looking out for our best interests.

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

#83

Post by CaptainOfCoit »

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.

> Is that common to only communicate only through email/github?

Absolutely. I've both taken over libraries as a maintainer and given away the responsibility of maintaining a library after only communicating via text, and having no idea who the "real" person is.

> I guess some maintainers of open source projects will be more cautious after this story.

Which is completely the wrong takeaway. It's not the maintainer who is responsible for what people end up pulling into their project, it's up to the people who work on the project. Either you trust the maintainer, or you don't, and when you start to depend on a library, you're implicitly signing up for updating yourself on who you are trusting. For better or worse.

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

#84

Post by EdiX »

rcxdude wrote: post #56
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 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 friction.

Philosophically, you are just shifting the attack vector around, you now need to compromise one of tools X, Y and Z, which are probably less under your control than the artifacts they produce.

> And systemd has in fact deliberately made the notification process simple specifically so people can avoid the dependency

People say this but I'm skeptical, this is the actual documentation of the protocol:

"These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable. If the first character of $NOTIFY_SOCKET is "/" or "@", the string is understood as an AF_UNIX or Linux abstract namespace socket (respectively), and in both cases the datagram is accompanied by the process credentials of the sending service, using SCM_CREDENTIALS. If the string starts with "vsock:" then the string is understood as an AF_VSOCK address, which is useful for hypervisors/VMMs or other processes on the host to receive a notification when a virtual machine has finished booting. Note that in case the hypervisor does not support SOCK_DGRAM over AF_VSOCK, SOCK_SEQPACKET will be used instead. The address should be in the form: "vsock:CID:PORT". Note that unlike other uses of vsock, the CID is mandatory and cannot be "VMADDR_CID_ANY". Note that PID1 will send the VSOCK packets from a privileged port (i.e.: lower than 1024), as an attempt to address concerns that unprivileged processes in the guest might try to send malicious notifications to the host, driving it to make destructive decisions based on them."

So technically you have to support unix domain sockets, abstract namespace sockets, whatever SCM_CREDENTIALS is, whatever AF_VSOCK is and the SOCK_SEQPACKET note is completely obscure to me.

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

#85

Post by christophilus »

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

The exploit didn’t actually run on those distros, though. Only on deb/rpm targets. So, effectively, it was stopped before it hit production.

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

#86

Post by simiones »

jorams wrote: post #54
hk__2 wrote: post #33

Earlier quoted context omitted.

> Or… just have downstream users run autotools as part of the build? See point 3: > 3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.

Whether it's autotools or not is not very relevant to point 1a. I'm also confused why point 1 leads to 1a, and not to the opposite of 1a. Source distribution tarballs should not contain code different from what's in the source repository. They should not contain automatically generated artifacts, since those should not be in the repository, since they are by definition not the source , but output of some kind of buil…

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.

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

#87

Post by Denvercoder9 »

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.

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

#88

Post by xorcist »

josephg wrote: post #53
disconnect3d wrote: post #23

Earlier quoted context omitted.

I would personally add: test your build scripts. There are so many bugs like the "added dot to disable landlock" added as part of this action (which can also be typos [0]), not to mention that relying on some tools in autoconf to set feature flags will just disable them if those tools are not present [1]. [0] https://twitter.com/disconnect3d_pl/status/17744965092596453... [1] https://twitter.com/disconnect3d_pl/statu…

I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring? Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogene…

Satire is so hard on the Internet and maybe I'm just thick headed. Just to clarify things, is that a suggestion to shove a JSON parser into either bash or autoconf?

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

#89

Post by Denvercoder9 »

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

> with one that checked if liblzma was being compiled in the same environment as OpenSSH

No, the attack didn't check for OpenSSH at build time, it checked whether it was injected into the ssh process at runtime.

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

#90

Post by lenerdenator »

Denvercoder9 wrote: post #81
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…

> 8. This sucks to say, but code reviews and handing off maintainership, at the moment, need to take into account geopolitical considerations. That won't help. There's no evidence that Jia Tan is a real name, or even a real person for that matter. If projects stop accepting contributions from asian-sounding names, the next attack will just use Richard Jones as a name.

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.

Post reply on HN