Big Ruby Security Update, Disclosure Debate

Ruby has patched some very critical problems submitted by Drew Yao of Apple. “The vulnerabilities stemmed from unchecked overflow conditions in several array-handling routines, and from an unsafe memory allocation in Ruby’s string processing.”

Worse, “the vulnerabilities, which impact versions 1.8 and 1.9 of the interpreted programming language, could allow a denial-of-service attack or lead to remote compromise…”

Security company Matasano’s blog entry on the matter says the nature of the vulnerabilities sent chills up their spines.

All three published vulnerabilities allow normal Ruby code to be coerced into corrupting the memory of the interpreter. They involve integer handling errors in the native code backing Ruby’s Array, String, and Bignum classes. These are core classes in Ruby, and don’t depend on the libraries or extensions that programs load. The vulnerabilities, which are common to all large C codebases, exploit the fact that numbers “wrap” when they hit the largest size allowable by the CPU (usually 32 bits), and the fact that negative numbers and very, very large positive numbers share the same underlying machine representation.

The ability to overwrite memory in the Ruby interpreter is basically the same thing as the ability to upload native machine code into the interpreter. There are thousands of locations in memory that, if overwritten, can redirect code to unsafe libraries or directly into input buffers (such as the contents of web requests). The conditions under which the vulnerabilities are exploitable depend on the Ruby programs you are running. But don’t gamble. Update as soon as you can.

The nature of the problem and the minimal disclosure are leading to some measure of distrust and reigniting the debate over how much developers should inform users and how soon they should do it. On the one hand, developers need to give users a chance to patch before everything goes wild. Full, immediate disclosure of the nature of problems opens the door to exploitation of vulnerabilities.

On the other hand, as Zed Shaw has noted in his fast (“20-40 minutes”) analysis of the changes that illuminate the gravity of the problems in ruby, it’s not rocket science to see what’s been changed to understand what was fixed and why it matters. Anyone can do this, including the criminal class and they’re more likely than “good users” to scour code in the first place. The irony is the number of naive open source advocates (especially the fucktards who say or write things like “Linux is better than Winblows!”) who boast about code access but, short of having to compile what’s not yet in Ubuntu Universe, don’t do a damn thing with it.

That debate will continue to ebb and flow. What won’t is the fact that an attacker can execute arbitrary code and/or cause denial of service in a vulnerable version of Ruby on a server using it. At will, and trivially: “…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.”

Patch. Review. Keep an eye on updates. Patch again. Repeat.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: