RPM Fusion, wiki defacement, and bug reporting

There are lots of ways to alert a project to a perceived security problem, but defacing its wiki is not high on anyone's preference list. Doing so does have one advantage, however: raising the visibility of the complaint—unfortunate though that may be. So, on the one hand, it is a truly obnoxious act, but on the other it draws attention to a problem that may have been languishing. A recent incident with the RPM Fusion project is a perfect demonstration of that.

RPM Fusion maintains a repository of RPMs for Fedora and Red Hat Enterprise Linux (RHEL). Those RPMs are for packages that Red Hat cannot or will not distribute for various reasons, typically legal issues such as patents. So, things like multimedia codecs, game system emulators, proprietary graphics drivers, and so on will be found in the repository. Three early repositories, Livna, Freshrpms, and Dribble, came together in 2007 to form RPM Fusion.

Users who wish to view internet videos or listen to MP3 files on their Fedora systems are likely to have added RPM Fusion as a source in their /etc/yum.repos.d directory by following the instructions on the RPM Fusion wiki. But those instructions were the target of some defacement on July 26.

A look at the history of the page shows multiple edits from Nikita Churaev (aka lamefun.x0r), interspersed with reverts from Nicolas Chauvet and Jonathan Dieter. The first change was evidently a test to see if a new user could edit the wiki to alter the download links for the packages that "install" RPM Fusion (i.e. place it into the system's Yum repository list). When that was successful, Churaev filed a bug in the project's Bugzilla noting that the initial download (install) of RPM Fusion is insecure. More defacement followed.

The complaints listed in the bug are quite sensible. Anyone can go in and change the wiki links, key IDs, key fingerprints, etc., to lead users to install malware. Even if those malicious edits are noticed and reverted quickly, there is still a window in time where users could be fooled. In addition, anyone can upload a GPG key to the public key servers that purports to be from the RPM Fusion project, so a malicious key that was listed on the wiki could easily be made to pass some basic sanity checks.

One possible malicious scenario would be for an attacker to change the key ID and fingerprints on the wiki to those of keys controlled by the attacker. Then, switching the links to the install packages to malicious versions would lead (some) users to download and install them, which would place the attacker's repository into the Yum configuration. That would allow the attacker to provide a steady stream of malware to the user that was disguised as RPM Fusion packages and all, seemingly, signed with an RPM Fusion key. There are other ugly possibilities too, of course.

One major underlying problem is that the wiki is not accessible over HTTPS, which allows for man-in-the-middle attacks. Clients using SSL/TLS (and checking the validity of the certificate) would be able to ensure that the web page data was coming from the project if that were offered. HTTPS wouldn't, of course, solve the problem of anyone being able to alter the wiki, but a static page or two with the key information that was served up over HTTPS would go a long way toward solving the problems Churaev is reporting.

In fact, an earlier bug filed by Churaev is explicit about that. That bug was filed at the end of 2012 and has seemingly not been touched since. More than a year and a half without any action on the bug appears to have been something of a trigger that led to the wiki defacement (which branched out further, to the wiki front page as well).

Dieter posted to the developers mailing list about the defacement problem. He recommended that the wiki be locked down. But Churaev was not impressed with that response, noting that the defacement problem had happened before, which should have served as a wakeup call. The thread died there, however, after two messages, which should probably be a bit worrisome to those who use RPM Fusion.

As Dieter pointed out in a comment on the most recent bug, though, insulting the project and defacing the wiki are not actually helping to solve the problems Churaev has identified. In fact, that kind of activity is counterproductive:

He went on to list some ideas for ways that Churaev could improve the situation. Others also commented on the bug report, expressing interest in helping to pay for an SSL certificate if that is what is needed. But, again, there was no official response. The bug is open, but so is the wiki. Project leaders are either not paying attention or not taking any visible action. That also should be a bit worrisome to users of the repository.

That's the real crux of the issue, in the end. It would seem that there have been a number of incidents (other defacements, Churaev's original bug report) that should have spurred action on these problems, but hasn't, for whatever reason. There probably isn't too much danger for attentive users, who are knowledgeable about keys, signatures, and the like, but the risk is certainly not zero. For less technical users, who might just follow instructions somewhat blindly, the risk is substantially higher—while still perhaps being fairly low in the grand scheme of things.

But the attitude of the project leaders matters. Even volunteers have some responsibility to secure their public sites, or to at least warn users of the risks. So far, at least, RPM Fusion has seemingly done neither. Those who use its repositories will want to keep that in mind.

It's a little hard to decide what to think of Churaev's role here. The situation is, in some ways, akin to companies that have vulnerabilities reported to them, but fail to take any action. In the past, that has led some to forgo the "responsible disclosure" path and simply to publicly report any bugs found. That is essentially what Churaev has done here—more or less, anyway. Will it lead to changes in the distribution of RPM Fusion's keys (at least)? It's an open question that is now at least more prominent than it had been ...