Now that the #xz backdoor is uncovered and contained, the work on analysing its inner workings is moving forward. By triggering function calls inside the binary payload in a safe environment, for example https://threadreaderapp.com/thread/1776691497506623562.html
Another though about the #xz near-miss. Anyone who thinks that closed source software is fundamentally better supported and maintained is, imo, not informed. I have worked at multiple places there the one person who really knew a system and maintained it left the company. It was still sold and used, but no one had the primary responsibility to maintain it. They might touch it once in a while when they had free time (between features for other "more important" projects) and added bugs every time.
Lasse Collin has posted an update on his plans for #xz and clearing up what happened: https://tukaani.org/xz-backdoor/ I hope he’s met with all the support and patience he needs.
You know how governments typically pay for creation & maintenance of physical infrastructure, and are seen as responsible for making sure at least not too many people are hurt by them, and Do Something when people are? (not that they always do, but at least there's some kinda expectation/demand)
And you know how that goes even if only civilians use those water pipes, roads etc, not just when the gov itself use them?
Maybe we should start thinking like that for digital infrastructure too?
#30DaysOfBiking, Day 5, Part 2: Went into the weekend a bit earlier due the time I worked during the Easter weekend on understanding and locally mitigating the #xz f🤬ckup. Ran some cycling related errands: bringing a rain jacket to #Transa for repair and visiting my #Brompton repair shop #Velofix for making an appointment for the next maintenance. The boss came out, pointed to their window and said "You're hanging in our window!" And indeed, there's a printed version of https://www.provelozuerich.ch/magazin/bromptonaut-unter-strom/
Das #BSI ist inzwischen auch aufgewacht und warnt vor dem #xz Backdoor. Das ist löblich, die Warnung selbst aber nicht ganz korrekt.
Die vielen Millionen Internet-Server laufen in den seltensten Fällen auf Bleeding-Edge-Systemen, sondern auf stabilen, wie etwa #DebianStable, #UbuntuServer, #SLES oder #RHEL. Keine der genannten Distributionen enthält den #xzbackdoor.
Ist das wieder nur schlafmütziger #Compliance Fick-Fuck einer deutschen Behörde, oder möchte man ...
And on MacOS, yeah, I also checked, and I had version 5.6.0. But the brew team says the malware was only for deb and rpm packages, so doesn't affect Mac: https://github.com/orgs/Homebrew/discussions/5243
Here is a very good video about the social aspect of #xz that should be required watching. The first couple minutes is about the tech details, then the rest about the open source hack.
But that first tech bit shows a build flag mixing in the exploit if you're running x86_64 Linux. Other platforms seem to be excluded. So add that to your recommendation / limitations you just gave.
#XZ : so from now on, companies will invest time and money on libre projects they depends on instead of vulturing everything they can, won't they ? No ?
This, from the naive and innocent days of just under a month ago, is worth re-reading in light of the xz backdoor:
"In essence, having a lot of dependencies results in two problems. The first is the burden problem, where each added dependency requires extra effort. That manifests in tasks such as keeping up to date with dependencies, but also requires extra work for downstream users like people packaging the project for a Linux distribution.
The second problem is a trust problem: each additional dependency is another team to trust and another codebase to validate. This trust problem is especially important to sudo-rs. As a setuid program meant for elevating privileges, all code that is compiled into sudo-rs has the potential to accidentally (or intentionally) give access to system resources to people who should not have that access. The setuid context additionally puts some constraints on how code is executed, and dependencies might not have accounted for that context. We could not expect any of our dependencies to take into account such a context either."
If you would like a well informed, accessible breakdown of the recent #xz backdoor issue on #linux - give Ubuntu Security Podcast episode 224 a listen. It’s only ~30 minutes in duration. Mostly not actually Ubuntu specific, and very digestible.
@dystroy
For the first time I'm starting to get PRs for one of my moderately popular projects, used by people who are potential targets just because they use it.
Meanwhile I'm putting lots of time into another project which is much more fun.
I'm grateful to the #xz attacker for showing me that it is best to let them sit there, with a little explanation and thanks, until I have time to review them properly.
Maintaining #FOSS comes with responsibilities we need to take seriously.