Does anyone know if this has been reported to the FBI and Homeland Security? Or can one just assume they will become aware?
What we know about the xz Utils backdoor that almost infected the world
301–310 of 336 posts
Re: What we know about the xz Utils backdoor that almost infected the world
#302Earlier quoted context omitted.
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.
> 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…
I don't think it's crazy for a maintainer to Google the person a bit, and if there is no positive match, ask the other person for at least a little bit of detail about themselves, like where they live (country/city), who they work for, etc. Maybe hop on a phone call or something.
In this case, Jia Tan just doesn't seem to match any real person we can find online. It's not like there's an elaborate online persona that they have really built.
While I don't want to put Lasse Collin on trial since he's a victim too, I do think he owes the community an update and explanation of what went down. It's not because we want to point fingers at him, but to learn from the experience.
Re: What we know about the xz Utils backdoor that almost infected the world
#303Earlier quoted context omitted.
> 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.
That's not what the above commenter said. This may be your interpretation but the above commenter is essentially saying "don't work with Chinese-sounding developers" and is the completely wrong take here. Jia Tan may or may not be Chinese but the core issue is the lack of basic vetting to make sure he/she/they are a real person.
Re: What we know about the xz Utils backdoor that almost infected the world
#304My 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…
There are a lot of bad to terrible takes here, ranging from hindsight 20/20 to borderline discriminatory:
3. The issue here has more to do with the generated tarball doesn't match source. You (i.e. distro owners) should be able to generate the tarball locally and compare with the generated artifact and compare. Autotools is just a scapegoat.
4. xz is used in a lot of places. Reducing dependencies is good, but trying to somehow say this is all systemd's fault, for depending on liblzma is not understanding the core issue here. The attacker could have found another dependency to social engineer into, or find a way to add dependencies and whatnot. It's very easy to say all these stuff in hindsight.
5. Again, I agree with you on principle that dependencies and complexity is a big issue and I always roll my eyes when people bring in 100's of dependencies, but xz is a pretty reputable project. I really really doubt someone would have raised an issue with adding liblzma or think that the build script would introduce a vulnerability like that. Again, a lot of hindsight talking here, instead of actually looking forward to how something like this could realistically be prevented. Too many dependencies are but it's not suddenly everyone will write their own compression libs.
6. Again, I mean, I don't disagree with you on principle but that is not the lesson from this particular incident. This may be your pet peeve but it wasn't like the integration with libsystemd would have raised anyone's alarm.
8. This is just a thinly veiled way of saying "don't work with anyone of Chinese descent". I don't want to use the R word but you know exactly what I mean. There's no evidence Jia Tan is Chinese anyway, or that this is done by China. We simply don't know right now, and as far as we know they could have used any western sounding name. The core issue here is that the trust was misplaced, and the overworked maintainer didn't try to make sure the other person is a real one (e.g. basic Googling). So what, if you don't work with any Chinese, if someone is called "Ryan Gosling" you automatically trust them?
---
I do agree with point 7.
Re: What we know about the xz Utils backdoor that almost infected the world
#305Why 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".
[deleted]
Re: What we know about the xz Utils backdoor that almost infected the world
#306Earlier quoted context omitted.
> Is libc a problem for the ecosystem? Absolutely yes. And also the size of the kernel. Those two currently have a much better guaranteed quality than systemd, thus systemd is a much more pressing issue. But they don't stop being a problem just because they are not the largest one.
> the size of the kernel Is mostly in the hardware support, only a tiny fraction of which is actually active. Linux has a lot of drivers, many of them are crap, but it's not obvious to me that Linux would be better off with no driver than a crap driver.
That tiny fraction is quite huge. Filesystems and networking support are well known problematic areas, the sound system is a chapter by itself, and Linux is full of old, should-be-unused interfaces that attackers successfully use once in a while.
Besides, the core part of the kernel is way too big for anybody to read. And any of it can interact with any other part.
Re: What we know about the xz Utils backdoor that almost infected the world
#307Why 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".
It doesn't seem to have been actually included in the Arch (binary) package but only because the backdoor build system itself didn't include the backdoor for Arch. If you cmp -l liblzma.so.5.6.1 between xz-5.6.1-1 and xz-5.6.1-2 there are only tiny differences. I'm guessing they didn't notice this before writing the advisory.
https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
Re: What we know about the xz Utils backdoor that almost infected the world
#308Earlier quoted context omitted.
Let's use the current theory that this is a state sponsored attack. If that's the case, another Jia Tan will be recruited. The identity of a single person simply doesn't matter. All that matters is that the attack was attempted. Consider the issue of candidates who lie in the interviewing process by hiring other people to interview on their behalf. Now replace "interview" with "attend conference". This is just adding…
It raises the bar quite a bit. Especially when you've met Jia Tan and the new Jia Tan is obviously not the same person. Meeting in person is quite literally the opposite of blind trust. Blind trust would be assuming that the person physically sitting on the other end of the internet connection and controlling Jia Tan's keys is the same Jia Tan you had lunch with a few months ago.
You cannot prove the person behind the keyboard is the person who is meeting up with people.
This is blind trust because of the assumption that the person is the same.
Re: What we know about the xz Utils backdoor that almost infected the world
#309Earlier quoted context omitted.
> systemd and libsystemd is an absolute mess how? Because they link against a third-party library? > is there a dependency graph that would show how many programs use a specific utility library Agree, important topic > is there a dependency graph that would show how many programs use a specific utility library Depends on the distro, but your package manager should be able to do that. On a global scale, that's likely…
Because its a very large monolithic piece of code, which causes issues with trying to audit it / brings it code that might not be necessary / increases attack surface
Well said… by someone who has clearly never opened the sources of systemd.