In 1995, when Linux 1.x was the hot new Linux kernel, early Red Hat founding programmers Marc Ewing and Erik Troan developed RPM. This software package management system has become the standard method of distributing software for Red Hat Linux-based distributions such as Red Hat Enterprise Linux (RHEL), CentOS Stream, AlmaLinux OS, and Rocky Linux. Unfortunately, there is a major security flaw in its heart.
Dmitry Antipov, a Linux developer at CloudLinux, the parent company of AlmaLinux OS, first discovered the problem in March 2021. Antipov stated that RPM would work with unauthorized RPM packages. This meant that unsigned packages or packages signed with revoked keys could be silently patched or updated without warning them that they might not be kosher.
Why? Because RPM never properly verified the handling of keys for revoked certificates. Specifically, Linux and leading RPM developer Panu Matilainen stated, “Revocation is one of the many unimplemented things in rpm’s OpenPGP support. In other words, you don’t see a bug as such; it’s just not implemented at all, similar to the flow “isn’t.”
How could that be? That’s because RPM dates back to the days when code functioning was the first priority and security was far secondary. For example, we don’t know whether the first RPM commit was made by Marc Ewing or Erik Troan because it was run as root. Those were the days!
Things have changed. Security is a much higher priority.
Antipov, who wears his hat as a team member of TuxCare (CloudLinux’s KernelCare and Extended Lifecycle Support), 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] Check that the key is valid and genuine, but not expired but not revocable. As far as I understand, all distribution providers were just lucky enough to never be affected. ”
You actually got lucky. Armed with an outdated key, it could be a breeze to inject malware into a Linux desktop or server.
Joao Correia, a TuxCare Technical Evangelist, asked, “Do you know how long it takes for the distributions to pick up the changes being sent to the code repositories?”
It’s hard to know. In general, the problem is that crypto is heavy. It takes a special background, a special experience and so on. Package management projects are running Package management, not crypto, so you don’t want or need to develop your own crypto libraries containing RPM and DNF. I’m not an expert in the crypto field to fix current DNF and RPM issues. I used the RNP library, a library known in the open source world that is already used in Mozilla Thunderbird, for example, but the library itself is not part of Red Hat or any other RPM-based Linux distribution. To take my fix as it is, you need to add it to the library first. This isn’t that fast so it’s hard to say how long it will take.
He fears it could take months for the fix to be released. For now, the vulnerability is still alive, good, and open to attack. Antipov and his team are considering opening a Common Vulnerabilities and Exposures (CVE) on this issue, as it is clearly a security issue in the end.
If I may be so bold, submit a CVE to Red Hat. This needs to be fixed, and it needs to be fixed now. In the meantime, administrators of RPM-based systems need to take a closer look at the patches to make sure they are legitimate patches.