Is Linux Really Secure?
David Both 
Over the more than 25 years I’ve been using Linux, one of my reasons for doing so—other than the fact that I hate Windows—is that Linux is more secure than that Redmond operating system. I’ve converted several friends to Linux in large part because of that level of security.
But, considering recent events, is Linux really more secure than Windows? Is it secure at all?
The initial problem
On March 29 of 2024, a security vulnerability was reported against the XZ library as CVE-2024-3094. This vulnerability creates what is known as a backdoor, a known and easy method for “CR4CK3R$”1 to access infected systems and use them for malicious purposes. The injected code does not perform any malicious acts by itself, it is simply the doorway for other code that is designed to perform malicious acts.
The XZ library is used by many programs to compress files and to extract the original data from a compressed file.
Impact
The impact of this vulnerability is minimal because it was discovered very early after it was injected into the XZ code. Read the article, CVE-2024-3094 XZ Backdoor: All you need to know, for a more complete description of the XZ backdoor vulnerability, including which distributions are affected and remediation steps you might need to take.
Red Hat RHEL, Ubuntu, Amazon Linux, Wolfi, and Gentoo are all unaffected by this vulnerability. While the upcoming and in-development Fedora versions 40, 41, and Rawhide are affected, the already released versions 37, 38, and 39 are not affected. However, Debian, Alpine, Kali, OpenSUSE, and Arch Linux are affected.
The remediation is to update to the latest XZ version. The specific version number differs among the affected distributions. See the link above for details.
The Real Problem
Although XZ has been fixed, it is not the real problem. The real problem is the underlying development tool that allowed this to happen. I’ll try to keep this description relatively simple:
The tool, Autotools, is a collection of tools developed by the GNU Project to perform the tasks required to automatically generate the files required to compile programs and then to compile them.
In a more technical article about the root cause of this problem, XZ backdoor and autotools insanity, Felipe Contreras, provides a scathing analysis of the true cause of the problem. Filipe is a software engineer and open source advocate. He’s blunt to the point of being obnoxiously rude. But that’s one of the things I like about him, and I agree with pretty much everything he writes in his post.
Felipe clearly demonstrates that Autotools generates huge amounts of obfuscated spaghetti code that is impossible for humans to adequately review. Its process allows anyone to create a bit of malicious code and have it included in the build of an otherwise safe package of programs such as the XZ code.
The best solution to fix the root cause of this problem, according to Felipe—and I agree with him based on my reading—is for everyone who is using Autotools to stop using it and revert to the safer methods previously used. Developers should simply make their own Makefiles so they know what’s in them and so can the people who review the code.
The Response
The open source community discovered the infected XZ files quickly (less than a month) and only a few of the newest versions of the XZ files were affected. The project has paused temporarily while they take remedial steps. Affected distributions were quickly identified and the mitigations were quickly identified. Appropriate notification steps were taken via CVE (Common Vulnerabilities and Exposures).
Fixing the XZ code was trivial—and as best I can tell, the fix has been completed. But it may take a bit of time for that fixed code to make its way into the affected distributions.
Conclusions
The first and most important conclusion anyone can reach after reading the many articles, emails, and posts I’ve read about this problem—especially Filipe’s—is that no software is ever completely secure. Ever. But most of us already know that so it’s really nothing new. However, this specific security breach should be a wake-up call for developers who should always know exactly what’s in their code and never make assumptions about the results of automated processes.
The second is that this particular backdoor could be used to infect any code anywhere if Autotools is used in its compile process. This is a terrifying thought. Imagine the chaos if malicious code were to be injected into code that runs the banking system, the Air Traffic Control (ATC) system, your refrigerator, car, or any of the billions of Internet Of Things (IOT) devices on the planet. What would happen if such code were to infect our so-called Artificial Intelligence2 (AI) tools?
Third, the open source community is really good about finding and fixing existing problems quickly, though perhaps not as good about listening to warnings like Felipe’s. I hope that last bit has changed.
For me, the bottom line is that despite this alarming incident, Linux is safe as only the best software can be. All software will have vulnerabilities, even some that are exploited. The open source community is the best in the world at locating and resolving those exploits and vulnerabilities. I trust all of my data, my finances, my books, my article drafts, my web site, my email server, and much more, to Linux.
Linux is still the safest operating system on the planet and I won’t use anything else. Ever.
Seth Kenlon 
Jim Hall 
Don Watkins