

Multiple vulnerabilities in Ruby - sant0sk1
http://www.ruby-lang.org/en/news/2008/08/08/multiple-vulnerabilities-in-ruby/

======
tptacek
None of these vulnerabilities is particularly scary:

* You were already pretty crazy if you were relying on Ruby "safe levels" to sandbox code, and I haven't seen anybody who does. If an attacker can eval Ruby code in your interp, you lose.

* An algorithmic DDoS against a bad regex is a classy attack against Webrick, but it's not as if once you fix it you're not vulnerable to DoS attacks.

* DL and "taint" don't play well together. You shouldn't have been relying on taint, but pretty much anyone can see that if an attacker can control the arguments to the DL functions, they get to jailbreak from the interp.

* The resolv.rb DNS spoofing problem is the 1995 problem, not this year's problem: monotonically increasing QIDs. The reason nobody noticed it until now is that nobody uses resolv.rb, which is a thread-safe async full-ruby DNS client hiding in the Ruby standard library. They ought to just remove it from the library.

------
sant0sk1
It'll be interesting to see if the Ruby core team handles this round of
vulnerability patches with more candor than the last.

Judging the amount of detail they've provided on this news post alone I'd say
they're off to a better start.

~~~
donw
Agreed. I'm a big fan of Ruby, but when millions of people are using your
product, you need to put some thought into the engineering process behind it,
and that includes putting some forethought into how you're going to handle
security problems.

Here's to hoping they get it right this time...

~~~
rcoder

      you need to put some thought into the engineering process 
      behind it, and that includes putting some forethought into 
      how you're going to handle security problems
    

Again, the ruby-core crew aren't thoughtless, or inexperienced; they have
processes in place for both normal releases and security advisories, and have
a pretty damn good track record for getting updates into the hands of the
folks who need 'em.

There are now far too many versions of Ruby out there in the wild for the core
team to effectively predict who is going to be affected by a particular issue.
Every Linux distro and release of OS X has a slightly different bundled Ruby
runtime, and most people don't seem to bother tracking the stable release from
the core team until something like the last round of security updates leaves
them scrambling to keep up.

The problem isn't the core team failing to handle security issues, it's the
community not giving a shit about the code that makes up the 'ruby' binary
until something goes wrong, and then not having any clue how to update their
systems and do basic compatibility testing.

~~~
donw
I stand corrected; I was under the impression that the big problem with the
last release, was that it broke core functionality that had been available in
all previous stable releases.

