I’ve known about the xz Utils hack for better than a week, but I didn’t appreciate the depth and breadth of the threat it posed, until I read this item (from today’s issue of the Cosmos Magazine newsletter). I suggest you read this. It’s an eye-opener about both the strengths and weaknesses of open source software, and how it’s developed.
Ernie
Weird that a Microsoft engineer had found the bug. Just goes to show though, that no one is safe on whatever platform, opensource or proprietary. It’s not just servers getting attacked anymore, it is everyone. The worst security risk to our computers are ourselves still though. So many people out there, that have no clue on the risky things they do on their computers, from downloading risky software, that say will speed up their Windows computers, when all it does is delete old registry files, Internet history, etc. Which you can do all ready within Windows itself, using it’s inbuilt software. No one learns about their computers, they just want something that works so they can watch YouTube, use email, Facebook, WhatsApp and so forth. This bug or exploit, was done by a software maintainer, begs the question though on what else is out there?
As I read the item, the person you call a maintainer was planted, so the malware could be inserted into the project’s source code. The fact that a Microsoft engineer discovered the malware’s not so weird when you consider how active Microsoft has been with Open Source recently. Regardless who found the exploit, the fact that it was found so quickly illustrates a strength of open source. The fact that it was possible to plant the so-called maintainer illustrates a weakness, and that’s a problem that we should find a way to fix.
My2Cents,
Ernie
As I have read, not really the source code was infected, but a precompiled binary.
The backdoor is super sneaky. It uses a little-known feature of the glibc to hook a function. It only triggers when the backdoored xz library gets loaded by a /usr/bin/sshd process on one of the affected distributions. There may be many other backdoors, but the one everyone is talking about uses the function indirection stuff to add the hook. The payload was encoded into fake xz test files and runs as a shellcode effectively, changing the SSH RSA key verification code so that a magic public key (sent during normal authentication) let the attacker gain access
Their grand scheme was:
sneakily backdoor the release tarballs, but not the source code
use sockpuppet accounts to convince the various Linux distributions to pull the latest version and package it
once those distributions shipped it, they could take over any downstream user/company system/etc
My mind is not even near to fully partially understand the whole story, but all that clearly shows, I have to TRUST the community.
(Otherwise what to install, and think it’s safe?)
I bet, if that MS employee would have not find it, someone somewher later would spotted it - probably after seeing suspicious network traffic on a compromised backdoored server.
I agree. If it had not been that Microsoft engineer who found the malware, it would still have been found by someone. That’s the strength of Open Source I was speaking to. As for the method actually used to get the malware included in the xz package, while I recognize the importance of understanding it, I wasn’t speaking to that alone. But, perhaps requiring source code submissions as opposed to binary ones could be a way of preventing such a method, or at least making it less likely to succeed in the future. If nothing else, that may be a start, at least if it’s a practicable solution.
Ernie
So, if I install everything from source, like in Gentoo, I avoid this bug. Correct?
Possibly, but to be as safe as possible, I recommend using the sources for the most current stable release. An updated package has been released (with the malware removed), so you could safely install the binary package if you prefer.
Ernie
Not really. I mean, among other things, keep in mind that Microsoft now runs GitHub, where the xz repo is hosted. (Meaning, “a Microsoft engineer” could even conceivably mean one of GitHub’s security people. Anyone who works at GitHub is, since 2018, “a Microsoft <something>”.)
I read some of the articles explaining the situation. It sounded like a couple of the test files in the build were corrupted and the build script was changed. From what I read on the BSD site, they said they weren’t affected because they use their own build files not the gnu autotools scripts. Also, the build files were in the tarball release. I believe I read that they weren’t in the source if you directly downloaded the source from github. Some of the articles mentioned the exploit made use of some glibc specific functionality so users on other operating systems or who use other C libraries like musl would likely not be affected. However, if the issue had not been found, further modifications that affected more users could have been added.
That is the big message. We were very lucky this time.
It is a bit sneaky corrupting a build file. That would have its effect in the computers of people who build distros, or those who build packages from source.
So Gentoo would not have missed out.
I assume binaries built with a corrupted build file may also have been affected… depending on what it did… so binary users would get it too.
Complicated.
If enough people are looking at the code, there are good odds that issues will be found. The other route is security by obscurity. If you’re using some unusual software that not many people use, it’s more likely, though not guaranteed, that someone won’t bother to target it. Some distributions such as Slackware switched over to using xz tarballs for their packages. The xz tarballs use less space than the standard tarball using gzip. I was investigating using it for some of the packages I build in place of gzip tarballs. Now I’m wondering if I should look into other alternatives besides tgz and txz. Maybe I should look into using code from a larger compression project with more developers or code from a small project that not many people have heard of or use? I believe I read somewhere that Arch Linux has done something with zstd tarballs. That alternative may be worth considering.