According to a linked article in the notes of Sam James (Gentoo mainttainer), "ldd" must not be used on suspicious binaries, because it loads them into memory that can lead to arbitrary code execution.

This is a very clear analysis of the shell stage obfuscation to inject the object code during the building process, written by Gynvael Coldwind:

xz/liblzma: Bash-stage Obfuscation Explained
https://gynvael.coldwind.pl/?id=782

I'm amazed by the sophistication level of the attack, from both a social and technical perspective, and it makes me wonder how safe are, in general, our digital infrastructures which are becoming so essential to protect our fundamental freedoms. I have the feeling that this incident will have long standing consequences for our FOSS communities, or at least I hope so.

4 members found this post helpful.

Yes, this "Jia Tan" user probably has a completely different real name, it might even be an organization consisting of several people. The scary thing with this is not what else the commits of Jia Tan has done to xz. The scary thing is that social engineering has been used to put malicious code in a project (xz) which opened up a backdoor in another project (openSSH) which did not even in itself have any dependency on xz.

Now this "Jia Tan" account has been exposed as a bad account and at least one more malicious commit has been identified in the xz repo. The scary part is not those identified malicious commits. The scary part is all unknown malicious contributions to projects. Malicious contributions might happen after social engineering to both open source and closed source projects. Maybe it is easier to make a malicious contribution to an open source project, but on the other hand it is also easier to later spot such contributions.

regards Henrik

Jia Tan was one of two known actors in this.

The code also revealed a weakness in SSH... Andreas raised the issue here https://bugzilla.mindrot.org/show_bug.cgi?id=3675

1 members found this post helpful.

The thing that concerns me is that we already knew this was a possibility, we just haven't seen many actual attacks like this. For these types of structural libraries and tools (SSH) these things get caught pretty quick. The real threat is with all these pip/cpan/npm/cargo systems that can autodownload thousands of dependencies for a single app. There are a lot of obscure modules for higher level languages that provide APIs for S3 storage and MFA flows that could be exploited to reveal a lot of secure info in a very short amount of time.

2 members found this post helpful.

When I started using Linux, most distros didn't even bother to sign their packages (though Arch did). Usually there was just an md5sum for users to check that they had downloaded correctly.

Those were more innocent times!

Do you refer to "Jigar Kumar" as the other bad actor? Again, that is probably a fake name, used for an account to put pressure upon Lasse Collin to accept Jia Tan as a new maintainer.

regards Henrik

Slackware started signing packages with GPG with Slackware 8.1 released year 2002. The first release of Arch Linux was also year 2002.

regards Henrik

At that time and for many years later I wouldn't have touched Slackware with a bargepole! I saw it as an expert hackers' system and not for the likes of me. How things can change...

which is funny because when I installed it for the first time -- Dec. '93 -- it was the easiest way to install linux on a i386 system... it was meant for non-expert... you are right, how things can change...

And still, I would say that it has been times and views that has changed rather than Slackware. Since the beginning in the early 90s the Slackware installation has allways been the same: Manually partitioning of disk before running installation scripts and bootloader settings by scripts at the end of the installation.

There might be other distributions out there that are easier to install, but once you have installed Slackware you have a system that you understand.

regards Henrik

Oops! We're getting off the point. This isn't a slackware fans fest, it's about the vulnerability of Linux code to bad actors.

right, I'm sorry.

back to the topic... this is an interesting proof of concept of the exploitation of the xz backdoor (obviously re-keyed since only the bad guy has the needed private key the exploit the original backdoor):

https://github.com/amlweems/xzbot

2 members found this post helpful.

Now that I think about it, wasn't Jia Tan & friends' modus operandi awfully similar to how ZhaoLin and the Russian dude whose nick I forgot usually behave?