Coda Hale { writing, projects, about, contact }

How Not To Fix A Security Bug

In which I am disappointed by a security vulnerability in Ruby.

November 25th, 2008

  • Tadayoshi Funaba opens Bug #794 in the Ruby Issue Tracking System describing a segmentation fault when huge decimal strings are converted into BigDecimal instances.

November 26th, 2008

  • Matz closes Bug #794 with r20359 to Ruby 1.9’s trunk.

November 27th, 2008 to June 2nd, 2009

  • Every site running Ruby 1.8.x which creates BigDecimal instances from client-provided data is vulnerable to a Denial-of-Service attack which Ruby Core developers have already fixed but not backported.

June 3rd, 2009

June 7th, 2009

  • ruby-core notifies the vendor-sec mailing list of the vulnerability.

June 8th, 2009

  • Bug 273213 is created in the Gentoo bug tracker to address CVE-2009-1904. Like most tickets for as-yet-undisclosed security vulnerabilities, the ticket was marked confidential and that “no information should be disclosed until [the vulnerability] is made public.”
  • Michael Koziarski creates a private GitHub project, bigdecimal-segfault-fix with a workaround for the bug.
  • Kirk Haines commits a change to the RubySpec project which adds a test to ensure Ruby implementations don’t “segfault when using a very large string to build [a BigDecimal].”

June 9th, 2009

June 10th, 2009

June 12th, 2009

June 13th, 2009

  • A fix is released for Debian Unstable. This fix contains the bug that Barry Hess found.

June 14th, 2009

  • No fix has been released for Ubuntu.
  • No fix has been released for Red Hat.
  • No fix has been released for Fedora Core.
  • No fix has been released for Gentoo.

June 15th, 2009

  • Ruby 1.8.7-p174 is released without the BigDecimal#to_f bug.


This is not a coordinated disclosure. This is a clusterfuck. If you are responsible for running a secure MRI/Ruby installation, your only hope is to pay attention to all changes made to Ruby’s trunk and backport any fixes yourself. Depending on your operating system vendor is not a viable strategy, as downstream vendors are not given sufficient advance warning and are presented with fixes which introduce other bugs or do not apply cleanly to the last released version.

Updated June 16th, 2009

  • Michael Koziarski dropped me a note to clarify a few things. First, his GitHub project was private and was only opened to the public after the vulnerability was announced. Second, ruby-core sent an email to the vendor-sec mailing list 48 hours before the disclosure. I’ve updated the timeline to reflect these changes.
  • James Ludlow let me know about a bug introduced in 1.8.7-p173 and fixed in 1.8.7-p174.
  • Updated my conclusions based on the new information. Still not happy, but more accurate in what I’m unhappy about.