Skip to content

Multiple vulnerabilities in RPM – and a rant

Last year in November I decided that it might be a good idea to fuzz the parsers of package management tools in Linux distributions. I quickly found a couple of issues in DPKG and RPM. For DPKG the process went very smooth. I reported them to Debian's security team, eight days later fixes and security advisories were published by both Debian and Ubuntu, the main distributions using DPKG. For RPM the process was a bit more difficult.

If you want to report a bug to RPM you first may wonder where to report it. The RPM webpage [1] is a trac installation which has its own bug tracker. However if you try to register an account there you'll get forwarded to an HTTPS site with an expired certificate that doesn't match the domain name. In case you are brave and tell your browser to ignore all warnings you'll be greeted by a broken-looking trac without any CSS. Should you proceed and create an account you will learn that this doesn't help you, because in order to be allowed to report a bug you first have to ask on the mailing list or in the IRC channel for permission [2]. That's probably the point where many well-meaning bug reporters give up.

Okay, but RPM originally stood for “Red Hat package manager” (I've been told that today it stands for RPM Package Manager), so maybe Red Hat feels responsible. So I reported three bugs with sample files triggering them to the Red Hat security team on November 20th. The answer was – to put it mildly – a bit dissatisfying. I'll just fully quote it: “Thanks for the report. We also received about 30+ crash reports in RPM from
a different reporter recently so processing all of them (yours and the
others) will take quite a bit of time. We simply don't have the resources
to spend hours upon hours analyzing all crash reports.”

Okay, so I wasn't the only one fuzzing RPM and the maybe bugs will be fixed some day. I waited. In the meantime I got contacted by another person who also had tried to report fuzzing bugs in RPM and who has made similar experiences (maybe the same person who reported the 30+ crashers, I don't know).

In February I decided to ask what the state of things is. I also gave them a 30 day period until I'd publish the bugs (I know that it's now long past that, I shouldn't have let this issue wait so long). I ended up having a call with a Red Hat security team member and exchanged a couple of mails. I learned that RPM has a Github repository [3], which contains fixes for some (but not all) of the issues I reported, however that's nowhere referenced on its webpage. I then fuzzed the current RPM git code again and found two more issues I also reported to the Red Hat security team.

Status today is that the latest release of RPM on its webpage – - is from July 2015, so all of the bugs still affect this release. However it seems there is an unofficial 4.13 release that's nowhere to be found on the RPM webpage, but Red Hat is using it together with some fixes [4]. And the Github repository says the latest release is 4.12.0, so according to three different sources three different versions are the current one (4.12.0,, 4.13).

One of the bugs – a stack overflow (write) - is still present in the latest code on Github.

Commend and Conclusion

This blog post probably reads like a big rant about how unprofessional Red Hat is in handling potential security issues. But this is contrary to my usual experience. I often see Red Hat developers being very active in the free software security community and often contributing in a positive way. Quite simply I expect better from Red Hat. This is not some dubious Enterprise vendor where I wouldn't be the least bit surprised of such a reaction.

The development process of RPM seems to be totally chaotic, it's neither clear where one reports bugs nor where one gets the latest code and security bugs don't get fixed within a reasonable time.

There's been some recent events that make me feel especially worried about this: An unknown person has created an entry in the Libarchive issue tracker [5] that points to an anonymous document [6] with a very detailed description of various security weaknesses in the FreeBSD update process (most of them are still unfixed). The most worrying thing about this is however that the anonymous post mentions the existence similar documents affecting multiple Linux distributions. These documents haven't shown up publicly yet and given the unclear nature of this incident it's hard to know whether they ever will become public or exist at all. But this should still be reason enough to have a closer look at potential security vulnerabilities in all pieces of Linux package management systems.

I haven't analyzed the RPM installation process in detail, so I can't say how likely it is that the RPM tool ever sees a malformed input file. It seems downloads happen over HTTP, but the first thing that happens is a signature check. As the signature is part of the RPM file it already needs to be parsed for this. The exact impact of these bugs would require further analysis. But independent of how likely this is I think the parser in such a crucial piece of software should be robust. It should be safe to use the rpm tool to show info about a file on the command line.


All bugs were found with the help of american fuzzy lop. Here are the bugs:

Stack Overflow in glob() / rpmglob.c.
Sample file (test with rpm -i [input]):
Unfixed in the current Git code.

Heap out of bounds read in headerVerifyInfo() / header.c.
Sample file (test with “rpm -i [input]”):
Git commit:

Null pointer access / segfault in stringFormat() / formats.c
Sample file (test with “rpm -i [input]”):
Git commit:

Out of bounds read in rpmtdGetNumber() / rpmtd.c
Sample file (test with “rpm -qi -p -- [input]”)
Git commit:

Finally one annoying thing to admit: In my original report I included another segfault in headerVerifyInfo() with unclear reasons. However I am now unable to reproduce this one. It may be due to compiler options, different command line parameters or dependencies on my system that have changed. For completeness I'm still providing the sample file:
(Ideally the RPM developers should include all those sample files in a test suite they regularly run against an address sanitizer build of RPM.)

Please also note that I expect this list to be incomplete and there are likely more issues that could be uncovered with further fuzzing. I'll test that once all the existing issues are fixed.


No Trackbacks


Display comments as Linear | Threaded

John C. on :

Red Hat is a joke of a distro and a joke of a company.

John D on :

And your opinion matters why, exactly?

Joe Buck on :

If I understand correctly, to exploit bugs of this nature on a Red Hat system you'd have to produce a corrupted .rpm and convince someone to sign it, which might also require you to trick them into installing the key that you signed the package with. But installing an RPM will execute installation scripts, as root. So there's no need to exploit data corruption to someone get an exploit: the victim is already giving you root on their system just by the fact that they are installing your RPM. So I think it's appropriate for Red Hat to treat bugs of this kind as lower priority than other security bugs (though ideally they should be fixed).

tasket on :

Ideally, the parts of RPM that should be fuzzed are the ones directly related to its security features. As @rootkovska pointed out already, that would be 'rpm -K' ... not 'rpm -i'.

I'd encourage Hanno to do a follow-up set of tests on the verification functions of both rpm and dpkg, because any distro that doesn't fail on a bad signature isn't worth worrying about.

Joe Buck on :

Sorry, s/to sign it/to install it/

Hanno Böck on :

Hi Joe, it would be enough to convince someone to use the RPM tool to show information about a file. There may be more serious bugs in RPM that can be triggered pre-signature check.

But that's all a bit beside the point I'm trying to make. I think this whole story tells that quite obviously the development process of RPM is broken, the information on the webpage is invalid and nobody seems responsible. My main point is not that I want to report a security issue in RPM - I want to report issues in the way RPM is developed.

Marius Schwarz on :

I myself have reported security issues to Red Hat in the past, and some are reviewed and fixed very fast and some, took them 3 years to fix. A Full Disclosure Timer and working Exploitvideos are improoving your chances of a fix dramatically ;-)

But it's not directly Red Hat's fault, it's how things in the linux community work. The Package Maintainer is not necessarly a RH employee, so he reviews your bug reports in his free time (mostly). He has to understand the impact, has to sort out reports, that are minor problems, and has to have a solution for the big ones, and sometimes, that does not come together.

The maintainer can be having a new job in other parts of the planet, be sitting right in a warzone, or has personal problems to fix, or he simply does not care anymore about it ( happens more than you may expect ).

I can only give you the hint, to push it if it's important and if needed build an exploit, show it to the press.. the rest will work out by itself, like in the TEAMSPEAK 3 vulnerabilities 3 weeks ago.

If it's in the wild, someone will fix it.

Faheem Mitha on :

> The Package Maintainer is not necessarly a RH employee

Then it sounds like RH should appoint a Red Hat employee as Package Maintainer.

Roland on : seems to be down/unreachable now.

Julian on :

Please look at the github repo and the Fedora package again. Your claims ("there is an unofficial 4.13 release that's nowhere to be found on the RPM webpage", "Red Hat is using it together with some fixes", "Github repository says the latest release is 4.12.0"), are absurd.

The github repository has a rpm-4.13.x branch, the latest (pre-)release of that being 4.13.0-rc1. This one is also listed on the RPM website.

The Fedora package is based on that pre-release. The f22 thing you linked to cherry-picks a few commits from the rpm-4.13.x branch (or 4.13.0 pre-release), hence the patch file names.

Jeff Johnson on :


Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

Form options