lib32-xz 5.6.1-2 multilib
Library and command line tools for XZ and LZMA compressed files (32-bit)
xz 5.6.1-2 core
Library and command line tools for XZ and LZMA compressed files
which is what I wished for, I guess. Is there any way to find out whether the unpatched version 5.6.1-1 has ever been installed in the first place?
I’ve seen a lot of internet panics in my life and it’s very easy to get caught up in it and act irrationally, and I often feel like a bad person for not worrying or getting as angry as everyone else.
We need cool heads. Being able to sort out the facts from the speculation is important. There’s plenty of both this time around.
however i would suggest employing a small degree of suspicion since it seems that there is still a lot that isn’t known (other attack vectors, etc.) - as of yesterday it appears analysis of the binary is in its early stages - i’ve been trying to watch the 2 IRC chats dedicated to conversation and reversing the code but there’s so much going on that it’s difficult for me to follow
However, the summary relevant to Arch/Manjaro is that the backdoor was injected at build time via code in the Makefile. The rules of the Makefile only included the backdoor if an rpm or deb package was built on amd64 platforms. As Arch/Manjaro does not build rpm or deb packages, so they are not affected by this specific backdoor. This is in addition to Arch/Manjaro not having the sshd/systemd integration that the backdoor leveraged.
This of course, does not rule out the possibility that there are other backdoors in the code, as it seems the the malicious actors had control for some time. This seems unlikely at present, although can’t be ruled out. If you’re using Arch/Manjaro in an actual security critical context, then uninstalling xz and related packages would be prudent until the code is audited. However, for most people xz should be just fine to use.
Exactly. The binary exploit code itself was never present on Arch or Manjaro at any time, so while analysis of it is certainly very interesting and educational it’s more of a pressing concern for those distros where it was present.
FWIW the exploit allows execution of remote commands via sshd (but only if they are correctly signed with the attackers private key - it’s a very security-conscious backdoor ). There are also a number of kill switches and other tricks in it which are further attempts to evade inspection and detection. For example, it disables itself if the TERM environment variable is set (because the sshd service environment wouldn’t normally have that set, so probably someone is trying to analyze it).
All very clever and interesting but some of the long-term lessons to be learned are much more basic;
There is no good reason these days for release tarballs to contain pre-generated artifacts, script or otherwise, that aren’t in the repository. This practice is a legacy hangover from olden times when installing a complete build environment might be expensive in terms of bandwidth or disk space. But this incident has shown just how easy it is to hide things in pre-generated autoconf scripts and the like, so it’s time to start insisting that release tarballs exactly match the repository code at the time they were created. If not then it would be safer to clone the repository and build from that instead (which Arch package tools can already do).
The famous xkcd #2347 comic just gets more relevant every year. The evidence so far suggests that “Jia Tan” obtained maintainer status on this project by using sockpuppet acounts to put pressure on the original lone maintainer (since 2009), who had started taking long breaks to deal with mental health issues.
I’d say it reveals the absolute opposite. If this were closed source like something in e.g. Windows, would it have been caught and dealt with so quickly?
that’s how i’d prefer think about it too, however – and with the understanding that i hate winblows and M$ – the other question might be, would it have happened at all given that there’d probably have been more eyes on the project
The core thing that happened here was a way to exploit a very common open source situation - one maintainer, doing everything for free in spare time in a toxic, demanding environment. This is a highly exploitable situation.
This specific scenario wouldn’t happen in a commercial environment. However, the whole attack was a social engineering attack and those in general can happen and happen everywhere, especially with high-profile government projects. In that regard, open source project is no better or worse.
). There are also a number of kill switches and other tricks in it which are further attempts to evade inspection and detection. For example, it disables itself if the 
