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

61–70 of 336 posts

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

#61

Post by kuschku »

tomohawk wrote: post #27
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…

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.

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

#62

Post by kijin »

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…

To clarify (1), we should not be exchanging tarballs, period. Regardless of whether it's different from what's in the source repository.

It's 2024, not 1994. If something masquerading as open-source software is not committed to, and built from, a publicly verifiable version-controlled repository, it might as well not exist.

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

#63

Post by rcxdude »

mrkramer wrote: post #49
yosito wrote: post #4

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

Are we ever going to figure out who Satoshi is? Probably not anytime soon but we can look for clues. Jia was obviously interested in OSS security and fuzzing[0] but my wild guess is that s/he is not a state actor. I would rather assume s/he is a hobbyist opportunistic hacker who got trigged by the thought "If I can exploit this, why not?". I assume he intended to build a botnet and do whatever s/he came up with. The…

I think this is somewhat unlikely. Timezone/timestamp analysis of their commits seems to show them working on it as a day job. And that they were obfuscating their location from the get-go (not 100% successfully). It may not have been a state actor or even paid, but it seems like they started with at least the intent to deceive about their identity and origin, and that they were working on it as more than just a hobby.

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

#64

Post by mrkramer »

4bpp wrote: post #58
mrkramer wrote: post #49

Earlier quoted context omitted.

Are we ever going to figure out who Satoshi is? Probably not anytime soon but we can look for clues. Jia was obviously interested in OSS security and fuzzing[0] but my wild guess is that s/he is not a state actor. I would rather assume s/he is a hobbyist opportunistic hacker who got trigged by the thought "If I can exploit this, why not?". I assume he intended to build a botnet and do whatever s/he came up with. The…

The interest in OSS-Fuzz was because it was used to monitor libxz, and so one of the necessary subgoals was to trick its maintainers into exempting libxz from a check that may have caught the backdoor, or at least drawn attention to it for unrelated reasons: https://github.com/google/oss-fuzz/pull/10667

So did he plan all this from the beginning or somewhere down the line he went full yolo?! I am looking at his mailing chat[0] and he seemed pretty enthusiastic about improving and fixing XZ.

[0] https://www.mail-archive.com/search?l=xz-devel@tukaani.org&q...

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

#65

Post by filmor »

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

The build scripts of OpenSSH are irrelevant. The malicious code is embedded on building an rpm or deb for liblzma itself and becomes active when the dynamic library is loaded. There is a recent PR for systemd that instead of linking to the compressors during build dlopen-s them when used (https://github.com/systemd/systemd/pull/31550) which disables this particular path, but any initial load of a backdoored liblzma makes sshd exploitable (see https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlx..., section "Analyzing the injected code").

Lennart Poettering stated on a mailing list that e.g. libselinux als links liblzma and ends up in a lot of services on SELinux-enabled systems.

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

#66

Post by kuschku »

supposemaybe wrote: post #50
delfinom wrote: post #21

Earlier quoted context omitted.

>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. They never did. In fact the systemd maintainers are confused on that point and adding documentation on how to implement the simp…

I said this days ago, but re timezones - they are meaningless as even GCHQ and NSA etc will place false flags in code which has any kind of risk of exposure. I first learned about those techniques from all the high profile intelligence agency leaks from the USA who were performing those themselves.

It's not that simple. You can falsify a lot of things, but you can't easily falsify the working hours at which you reply to issues or push commits without taking a lot of care. Especially when DST has to be considered.

Sure, the +0800 timestamps are definitely fake. A handful of timestamps that were later scrubbed show +0200 and +0300, though. And all the commits match 9am to 6pm working hours if you interpret them as +0200/+0300. The working hours even shift around correctly with the DST change.

The issue is that russia doesn't observe DST anymore. That leaves Bulgaria, Cyprus, Estonia, Finland, Greece, Israel, Latvia, Lebanon, Lithuania, Moldova, Romania and Ukraine. Very few of those have the infosec capabilities needed for something like this.

Jia Tan was registered in 2021, but first sprung into action during the buildup to the russian invasion of Ukraine 2022.

Jia Tan also used a VPN provider that's headquartered in the US. That only makes sense if they're in a US-aligned country, as using a US VPN would give the US more insight into what you're doing, and only protect you from other countries.

Personally, I'd guess that it was Israeli intelligence. But Finland, where the original XZ author lives, is another interesting possibility.

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

#67

Post by gumby »

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.

I philosophically and fundamentally hate this suggestion, but have to agree with it. It's going to make porting harder, but is sadly a cost worth paying.

> dependencies are maintenance burden and a security risk, this needs to be weighted against the functionality they bring in

Tough call. A major library is more likely to be bug fixed and tuned than something you write (which is a good reason to use them which is what makes them attractive as an attack vector). Getting this right requires taste and experience. The comment says "depending on large libraries for small amounts of functionality [is bad but thought to be good]". What constitutes "small amount" vs large requires experience. Certainly cases of this tip my bias towards re-implement vs re-use.

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

#68

Post by LudwigNagasena »

supriyo-biswas wrote: post #26
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.

If you’re being berated by multiple people as to your speed of delivery, then it is not unexpected for them to be convinced that they are somehow the problem, and transfer the project to whoever they feel at the time is the best choice without thinking through their decisions. However, knowing a person personally doesn’t necessarily solve the problem. I used to work on an open source project a long time ago (under a…

He wouldn’t be able to do more than that if publicity were expected from core maintainers. Maybe he is trying to do the exact same thing with another project at this very moment.

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

#69

Post by AshamedCaptain »

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

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

#70

Post by imglorp »

netol wrote: post #47
thinkingemote wrote: post #39

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

If LEO is involved, they wouldn't be disclosing evidence to avoid the public interacting with suspects or possibly leapfrogging them and tipping off someone new.

In this case the public would benefit from knowing quickly who are the bad actors and what other projects they touched.

Post reply on HN