SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
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.
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.
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.
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.
Slackware started signing packages with GPG with Slackware 8.1 released year 2002. The first release of Arch Linux was also year 2002.
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...
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.
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):
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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.