Distributions face the MoinMoin and Rails vulnerabilities

MoinMoin is a well-established wiki system with a long list of deployed sites. Like any web application, MoinMoin is in a sensitive position with regard to security: it tends to be directly exposed to the Internet, and, thus, must be able to handle anything that any attacker, anywhere in the world, might throw at it. Similar things could be said of the even more widely-used Ruby on Rails framework. Unfortunately, even in the most careful project, security problems will happen, leaving users exposed. How have distributions responded to the most recent MoinMoin and Rails vulnerabilities? As of this writing, the picture is not entirely encouraging.

Moin is less

MoinMoin's security record, as a whole, is not particularly bad. A look through the LWN vulnerability database shows a number of problems in 2009 and 2010, mostly of the cross-site scripting variety. There was only one vulnerability in 2011, and two in 2012. But the final 2012 vulnerability is not a small one: any attacker with write access is able to execute arbitrary code on the server. Since the purpose of most wiki systems is to give write access to the world (it takes considerable effort to revoke that access generally on a MoinMoin site), this is a widely exploitable vulnerability indeed.

One of the first victims was the Debian project, which disclosed a compromise on January 4. The Python project has also disclosed that its wiki site was broken into. Given the prevalence of the MoinMoin system, and the handy list of waiting victims deployed sites posted by the project, it seems almost certain that there are other compromised sites out there. Anybody running a MoinMoin 1.9.x site that has not yet been patched should probably stop wasting time reading this article and fix their site.

But where is that fix to come from? Most of us, most of the time, outsource the business of integrating security patches to our distributors. That is one of the biggest advantages of running a well-supported distribution: we do not need to stay on top of every single vulnerability that gets reported. It is sufficient to install updates from the distributors occasionally and all should be well thereafter.

As of this writing, only two distributors — Debian and Ubuntu — have issued advisories for the MoinMoin vulnerability. None of the others have put out a fix yet. Some distributors, naturally, have no need to do so; MoinMoin is not shipped in Red Hat Enterprise Linux (and the version in the EPEL repository is old enough to not be vulnerable, but also old enough to be unsupported and possibly subject to an unknown number of other problems). Neither SUSE nor openSUSE appear to ship MoinMoin at all. But others are still shipping a vulnerable version.

Fedora ships vulnerable version 1.9.5, for example; the vulnerability shows in the project's bug tracker, but no fix has yet been issued. The same applies to Gentoo; as of this writing, the bug entry suggests that an advisory is in the works, but it has not yet appeared. Linux Mint does not issue advisories at all; it's hard to say whether this distribution has picked up the fix or not. Anybody running Mandriva Linux is stuck with an old package, but that should be relatively low on their list of problems at this point.

Whether ten days (or more) is too long to wait for a fix for a huge security hole is, perhaps, a matter of perspective. In any case, users of a community distribution who are not paying for support have limited grounds for complaint. Community distributions have limited resources to put into security updates, especially during holiday periods, and a package like MoinMoin is not necessarily at the top of the priority list. Delays will happen, sometimes, though one would wish that they did not happen for problems of this magnitude.

Perhaps what is needed is a way for distributors to inform users of important vulnerabilities that cannot be immediately fixed. In this case, there are workarounds that a MoinMoin administrator can apply to secure a system (see the MoinMoin security fixes page for details) until a proper patch can be applied — but the administrator has to know that (1) there is a problem, and (2) a short-term workaround exists. If a distributor is unable to issue a timely advisory with a fix, perhaps they should at least consider issuing an advisory with a warning and any useful information that may be available?

Rough ride for rails

The Ruby on Rails project disclosed an SQL injection vulnerability on January 2, though the fact that this vulnerability already was known as CVE-2012-5664 suggests that it had been discovered earlier than that. On January 8, the project followed up with advisories for CVE-2013-0155 and CVE-2013-0156, the latter of which exposes most Rails-based sites to code-execution attacks. Thus far, the only distribution to issue updates is Debian. Most community distributions ship a version of Rails, and they are all shipping a vulnerable version as of this writing.

Once again, the advisories from the Rails project include workarounds for those who cannot immediately update their systems. Rails site administrators should be tuned into those advisories, but some certainly are not. Once again, an early warning from distributors might well save some of their users from considerable grief. Distributors are certainly aware of the problems and their workarounds, and they have a unique communication channel to their users. Perhaps, in cases where a fix cannot be made available right away, some sort of heads-up message could be sent out?

In the end, even users of relatively slow-to-update distributions may be better off than those who had to install MoinMoin or Rails from source because their distribution did not ship it. Every one of those hand-installed systems will remain vulnerable until the administrator hears that there is a problem, or, even worse, notices that the system has been compromised. Hopefully, most administrators will manage to get their systems updated before the worst happens. But it's hard to avoid thinking that some of our distributors could have done a little more to help them.

---

(Log in to post comments)