Ruby security flaws expose release process problems

Some serious integer overflows in the Ruby language were recently discovered and fixed, but the process has left some in the community unhappy about how it was done. One of the biggest problems was that the official patched versions of the language broke its signature application: Rails. The overflows may lead to arbitrary code execution which left some users in a quandary, trying to decide whether to close known holes in the language or to keep their web applications running.

There still seems to be some question about whether the holes are exploitable or not, but one thing is abundantly clear: they were fixed in the public CVS several days before any kind of security announcement was made. It was made worse by referring to the CVE numbers in the commit message. For anyone looking for a possibly exploitable Ruby flaw—one that had yet to be publicly announced—that would be a glaringly obvious place to start.

When a release and announcement went out, some of the versions specified would cause Rails, the web application framework, to segfault. No new updates have been posted to the Ruby language web site leaving distributions and users to fill in the gap. Some frantic scrambling can be seen on a thread on the ruby-talk mailing list as folks with production Rails applications cast about for solutions.

Part of the problem may stem from the number of separate language versions the Ruby team is trying to support. Three stable versions (1.8.5, 1.8.6, and 1.8.7) as well as one development version (1.9.0) are all affected by these vulnerabilities. Unfortunately, all four of the updated packages had one or more problems that either didn't fix all of the vulnerabilities or broke Rails. Those are still the versions suggested as a fix as of this writing.

The new versions were based on the latest code in the CVS tree which evidently had not been tested completely. There are several test suites available for Ruby and Rails that would have caught these problems, but they apparently were not run. It is certainly important to get security fixes out quickly, but introducing other vulnerabilities and/or incompatibilities with existing code is a rather high price to pay. As is waiting ten (and counting...) days for a proper fix from upstream.

For the most part, Linux distributions have resolved the problem for themselves by either backporting the fixes into the version they already support or by fixing the updated version provided. For example, Fedora 9 has done three separate releases to fully resolve the problem, the first to upgrade to the suggested upstream version (1.8.6p230), a second to resolve a segfault introduced somewhere between p114 and p230, and a third to handle the problem of Rails being broken.

There is some indication that the Ruby team does not consider the flaws to be exploitable for code execution but, if so, they are still clearly denial-of-service vulnerabilities. The continued silence, at least on the official website, should also give one pause. The release process for Ruby seems to have fairly serious holes in it. This has caused some to issue a plea for a release process on the ruby-core mailing list.

In addition, Dominique Brezinski claims that these bugs or some that were closely related were disclosed several years ago (see comment 43) and essentially ignored at that time. This is disconcerting for a language that is being increasingly used in web applications and other internet-facing services. One can only hope that this incident will serve as a wake up call to the Ruby developers. Failing that, if additional incidents like this occur, it may instead serve as a wake up call for those who depend on Ruby.