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.
Accusing the ruby-core folks of a lack of candor in their handling of the previous round of vulnerabilities isn't really fair. Once the issues were effectively documented and explained, they released updated versions of Ruby 1.8.6 and 1.8.7 quite quickly.
The problem was simple that the core team doesn't use Rails, so they didn't test the patches they produced with non-trivial Rails apps. When other people did that testing, they got segfaults, freaked out, and basically tried to tell the core team that their release process was shit, and that they should let a bunch of outsiders tell them how to manage their releases.
Personally, I was embarrassed to be part of the English-speaking Ruby community during that entire episode.
I think that there are problems on both sides of this.
On the Ruby side, it makes a lot of sense to have Rails be part of the testing process, simply because it is such a prominent Ruby application framework. This doesn't mean that the Ruby people need to fix Rails, just that they should be aware when a core update breaks it.
On the Rails side, a bit more understanding, and a willingness to jump in and help, would go a long way.
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.
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.
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.
If the author doesn't want to put the appropriate processes in place to handle security problems, bug fixes, and the what, than this is of course his prerogative, but he should find it no surprise when he gets roasted on a spit by the user community that surrounds him.
People get angry when tools that they depend on don't work, regardless of whether or not they had to pay for those tools. A cavalier attitude towards the user-base will only incense them further, and while it may not matter to the tool-maker that people are going elsewhere, rather than use his free tools, the negative press can easily destroy a career or ten.
I'm not saying that this is right; merely that this is the way things are.
I agree that as a developer of an open source project, it helps your project to be ... helpful. But at some point, after it's clear that your project is essential, you can defer some of that work to the user community.
Want that feature? Send a patch (because, yeah, that's a good feature... but I don't need it and I don't feel like writing it.)
* 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.