OStatic

Last week, members of the Ruby community received word that all but the most recent versions of the language contain a serious security hole, and should be upgraded immediately. The security problems were announced on the Ruby language site, as well as on many mailing lists and in Ruby-related blogs. The solution, as proposed by the official announcement, is to upgrade to a more recent version of Ruby, either by recompiling it, or by retrieving a more recent version via your operating system's update service. (As was pointed out on the blog for Ruby on Rails, don't upgrade all the way to Ruby 1.8.7 unless you're running Rails 2.1.)

The announcement indicated that the security problem allows an attacker to potentially execute arbitrary code from a remote location. In other words, this means that using nothing more than their own computer, someone could attack a Ruby-powered Web site, executing any programs they want on the server. If I know that your site is vulnerable, then someone with an understanding of the vulnerability could delete all of your files, or upgrade your operating system, or spy on your Web traffic. Needless to say, this is the sort of thing that you don't want to have on any public-facing site.

Other than that general description, what is the problem? Well... the powers that be aren't telling. At least not yet. Computer security problems are often announced only when a fix is already available. Even after the fix is available, the specific vulnerabilities are often not discussed until weeks or months later, giving system administrators a chance to upgrade their computers.

Now, you might think that this is a reasonable course of action. And indeed, many of the world's computer security experts would agree with you. But many think that this is a foolish or naive way to approach things. After all, particularly when we're dealing with open-source software, it's not that hard for someone to look through the "changelogs," look at what has been modified since the previous version, and use that information to understand the vulnerability.

This is so simple, in fact, that many security experts argue in favor of what they call "full disclosure" -- the immediate and complete description of any and all software vulnerabilities. Without full disclosure, they say, vendors don't feel the need to release security updates very quickly, leaving everyone in the dark except the people who might exploit the problem.

People opposed to full disclosure say that large organizations need time to update their computers, and cannot do so within hours or even days of a security announcement. Postponing security announcements isn't an ideal situation, they argue, but full disclosure is even worse, giving ammunition to people who would otherwise have had to struggle to find it.

The argument over full disclosure is a long-standing one, with e-mail lists such as Bugtraq catering to its adherents, and organizations such as CERT taking the more cautious approach.

The thing is, the nature of open-source software means that even one knowledgeable person can effectively turn a cautious security alert into a full-disclosure report. We saw this clearly over the weekend, when ex-Ruby hacker Zed Shaw posted a long note to his blog, describing not only Ruby's vulnerabilities in detail, but also the methods that he used to uncover these problems -- which, he claims, took him less than 30 minutes. Zed writes about this with his typical, er, color, pointing to what he sees as not only foolishness in the lack of full disclosure, but also the quality of the original C code that caused these problems.

• security
• ruby
• changelogs