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
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.
to post comments)