Major Linux RPM problem uncovered
In 1995, when Linux 1.x was the hot new Linux kernel, early Red Hat founding programmers Marc Ewing and Erik Troan created RPM. This software package management system became the default way to distribute software for Red Hat Linux-based distributions such as Red Hat Enterprise Linux (RHEL), CentOS Stream, AlmaLinux OS, and Rocky Linux. Unfortunately, hidden within its heart is a major security hole.
Security
Dmitry Antipov, a Linux developer at CloudLinux, AlmaLinux OS's parent company, first spotted the problem in March 2021. Antipov found that RPM would work with unauthorized RPM packages. This meant that unsigned packages or packages signed with revoked keys could silently be patched or updated without a word of warning that they might not be kosher.
Why? Because RPM had never properly checked revoked certificate key handling. Specifically, as Linux and lead RPM developer Panu Matilainen explained: "Revocation is one of the many unimplemented things in rpm's OpenPGP support. In other words, you're not seeing a bug as such; it's just not implemented at all, much like expiration is not."
How could this be? It's because RPM dates back from the days when getting code to work was the first priority and security came a long way second. For example, we don't know whether the first RPM commit was made by Marc Ewing or Erik Troan because it was done as root. Those were the days!
Things have changed. Security is a much higher priority.
Antipov, wearing his hat as a TuxCare (CloudLinux's KernelCare and Extended Lifecycle Support) team member, has submitted a patch to fix this problem. As Antipov explained in an interview: "The problem is that both RPM and DNF, [a popular software package manager that installs, updates, and removes packages on RPM-based Linux distributions] do a check to see if the key is valid and genuine but not expired, but not for revocation. As I understand it, all the distribution vendors have just been lucky enough to never have been hit by this."
They have indeed been lucky. Armed with an out-of-date key, it could be child's play to sneak malware into a Linux desktop or server.
Joao Correia, a TuxCare Technical Evangelist, asked: "Do you know how long it takes for the distros to pick up the changes that are submitted to the code repositories?"
Antipov replied:
That's hard to know. In general, the problem is that crypto is hard. It takes a special background, some special experience, and so on. Package management projects are doing package management, not crypto, so they don't want, and don't need to, develop their own crypto libraries to include RPM and DNF. I'm not an expert in the crypto field to be able to fix current DNF and RPM issues. I've used the RNP library, a well-known library in the open-source world, already used in Mozilla Thunderbird, for example, but the library itself is not a part of Red Hat or any other RPM-based Linux distribution. So to take my fix as is, for the moment, they need to add it to the library first. This is not so quick, so it's hard to say how long it will take.
He fears though it may be months before the fix is released. At the moment, the security hole is still alive, well, and open for attack. Antipov and his team are considering opening a Common Vulnerabilities and Exposures (CVE) about the issue since, in the end, it's clearly a security issue.
If I may be so bold: File a CVE with Red Hat. This needs fixing, and it needs fixing now. In the meantime, administrators of RPM-based systems will need to take a closer look at the patch programs to make sure they are legitimate patches.