Slashdot Mirror
Major Security Hole Found In Rails
mudimba writes "A major security hole has been found in Ruby on Rails. Upgrading to version 1.1.5 is extremely urgent, and all previous versions except those "on a very recent edge" are affected. Details on the exact nature of the flaw will be coming soon, but the rails team has decided to wait a short time before disclosure so that people can have a chance to upgrade their servers before would-be-assailants are armed." Update: 08/10 13:56 GMT by J : Now they're saying only the last six months of releases are affected: 1.1.0 through 1.1.4.
...and hundreds die in the resulting crash. When interviewed later the conductor said that he wishes he was told where the hole was so he could've stopped the train in time.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
It's kind of interesting to know how many (or few) will be affected by this. I know several people who 'play' with Ruby as a fun new toy, but I know of few if any large-scale, high-traffic sites that use it.
the hackers are busy diffing the new release against the previous release to determine exactly what the hole was...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
patriotichackers ( some Kurdish d00d's ) have been mass defacing sites all night. yup. vi and apache baby.
This is an example of why many major industries stay away from the "bleeding-edge" of tech products.
Only when something has been in the market long enough for people to find the holes, either by internal testing or by discovery of in-the-wild exploits can it be considered for the "higher" end of the market. It's unfortunate that it has happened to Rails, which is a great framework but it's another reason to staty with the more established web frameworks such as JSP/Struts.
"RTFA suddenly seemed like a good idea."
They are telling everyone to upgrade, that's how they know.
But this strategy works so weel for Microsoft.... how could it be wrong :-)
Alex
Ah, computer dating -- it's like pimping, but you rarely have to use the phrase "upside your head" -- Bender
I was wondering if more security holes like this will show up and given an easier window for n'er-do-wells into OSX security.
Just a thought.
Ex nihilo nihil fit.
how can people know that they need to upgrade their server?
Um... by saying, like they did, "patch fast"? You seem to have completely missed the difference between telling people there's a hole (allows people to fix it but makes people have to find the hole to exploit it) and detailing what the hole is and why it's a problem (a free lunch for the malicious). The users are aware that a patch needs to be made; the would-be-attackers aren't aware of the compromising details.
The kink, as noted elsewhere in this thread, is that it's a flag that tells those would-be-attackers that there IS a large hole at the moment, but the tradeoff - users can in general update faster than it takes to find the hole and write an exploit for it - is ok here.
Browsing with +2 to insightful posts and a higher threshold makes the average post seen seem a lot more ingenious
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
It contains VERY important details that should have been in the summary.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
I find it incredible that people are going 'Oh look - see!! we told you rails wasn't ready for 'enterprise' because look! it's got security flaws"
yeah RIGHT, like *every* fuckin' bit of software isn't full o' holes
I reckon the rails guys are handling this pretty well, makes sense not to just release the details straight off the bat, give people a couple of days to plug the holes then they can discuss the flaw
fuckin' hell it's not like MS hasn't had to do countless 'immediate' patches
people are using this whole thing as an excuse to unfairly judge rails - hell if you don't like it then at least argue against it based on genuine issues with it - which I'm sure there must be, since there are pros and cons for any software
Doesn't the patch itself give away the location of the flaw? Comparing the size of files in the two installations should tell you which parts have been patched. I'm assuming a serious flaw means an explotable buffer overflow.
I wonder if this is related to their hacked wiki page?
Ruby on Rails Wiki
Anyone have information on this?
Penny Arcade is the worst advertisement for Rails there is.
I'm surprised the 37 signals guys haven't done a freebie consulting job to get their shit straight.
(or maybe they have and PA is a simply realistic example of RoR under load...)
No, I did not read the f***ing article!
http://wiki.rubyonrails.org/rails/pages/Security
Service Temporarily Unavailable
Seems an appropriate response!
Patch available here.
http://savingiceland.org
Diff-ing shows some new tests on Topic.find, including this aptly named test: test_sql_injection_via_find
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
I read that as:
Rails has a security flaw and it's not being derailed.
Well, it is being derailed, right ?
Religion is what happens when nature strikes and groupthink goes wrong.
it's You
Maybe they should switch to a safe language that prevents buffer overflows and protects programmers from themselves.
Oops.
http://blog.evanweaver.com/articles/2006/08/10/exp lanation-of-the-rails-security-vulnerability-in-1- 1-4-others
$LOAD_PATH.select do |base|{ file_kinds(:lib) * '|'}/) || base =~ %r{rails-[\d.]+/builtin}
base = File.expand_path(base)
extended_root = File.expand_path(RAILS_ROOT)
- base[0, extended_root.length] == extended_root || base =~ %r{rails-[\d.]+/builtin}
+ base.match(/\A#{Regexp.escape(extended_root)}\/*#
end
Not seen the context (so this is guesswork), but looks suspciously to me like you could supply a path like;
RAILS_ROOT/../../../../etc/passwd
Or something substantially similar to it...
--- Nick, hard at work
reviewing the diff between the versions, this is what I found:
1. a new test at rails/vendor/rails/activerecord/test/base_test.rb for SQL injections on ActiveRecord::Base.find
2. in the changelog for actionpack, we have:
* Added ActionController.filter_parameter_logging that makes it easy to remove passwords, credit card numbers, and other sensitive information from being logged when a request is handled. #1897 [jeremye@bsa.ca.gov]
So, I'd say the problem is on some of those.
Details of the exploit can be found here: http://blog.evanweaver.com/articles/2006/08/10/exp lanation-of-the-rails-security-vulnerability-in-1- 1-4-others
wow, an unmodded score of -1. Now that is impressive.
Tharkban (It is a signature after all)
I will admit right now that I have not used Ruby on Rails. And if that code is any indication of how Ruby on Rails is coded, I want no part of it.
Put simply, that is some truly awful code. I'm not sure if it could get any more unclear. When it comes to writing secure, solid software products, you need absolute clarity. The more obscure your code is, the easier it is to miss corner cases or invalid inputs. It's missing those cases that often leads to severe security exploits.
In some ways the current growth of Ruby outside of Japan parallels the growth process that Python went through during the later part of the '90s: making the transformation from obscurity to garnering the widespread attention of various nebulous Internet luminaries who step forward to profess its superiority to mainstream business languages in terms of flexibility and rapid deployment. Like early Python growth much of the exultation stems from the perceptions of a web framework, with even Apple Computer coming forth to associate its brand with Rails and high-traffic sites like Penny Arcade transitioning to the framework.
Some part of the growth of Ruby's recognition may be explainable in terms of the protracted development of Perl 6 and its ever-more baroque syntax, dissatisfaction with the Java-like direction the PHP language has been taking, and some waning interest with the cost of developing Java solutions to problems that are not compute-bound. I suspect that it is the dissatisfaction of web developers with the direction of their tools that makes them most susceptible to the siren call of new languages, especially those professing the ability to write the same programs in a much shorter period of time with more clarity. Application developers are slower to adopt the use of new languages outside of the domains of scripting and plug-in development, with the majority of desktop software meant for the home user still being developed in C, C++, and in the case of the growing Apple market: Objective-C.
It is because of this obstinacy that application developers have that much of the early successes of languages like Python and Ruby rise upward by following Java's path into the back-end with what become flagship projects that come to represent the language to adopters and spectators in its early form. Python had its Zope and now Ruby has its Rails.
Unfortunately this monocular fixation is a double-edged sword, and just as the successes of Rails can raise Ruby itself upward and spark new interest in developers that will branch out the competency of the available libraries, bad publicity for Rails could mute continued interest in Ruby, and losing the favor of its current famous advocates could spell the death of its potential to breach outward into a larger audience. It is for this reason that it is important for Ruby developers to ardently diversify the public successes of Ruby so that the sensational headlines of the Internet news cycle and the fickle nature of developer fashion do not spell an end to a promising beginning.
Flaws in software are inevitable, but when the spotlight is shining down upon you it is the spectacle of these flaws that will be remembered by the over-sensitive minds of managers when the time comes to decide what architecture to use for new developments. Diversifying the splotlight of Ruby will make it less susceptible to such damage.
I agree. I recently built my first major Django site ( http://www.trogger.de/ -- shameless plug!) and used that project to learn Python and Django. All along I was really enjoying myself (as opposed to all the previous J2EE development that I've done) and felt incredibly productive.
This is, of course, in part due to the Python language, with its dynamic features and the way it just "feels" right. But a large part was also the way the Django guys just 'get it'. I like their ORM. The database structures they generate make sense to me. I prefer developing an OO programming model abstraction and having that mapped to the database, rather than having the database introspected and then developing against the results. Django's way just feels more natural to me.
The recent release of Django 0.95 was a major effort and an important milestone. Judging from the roadmap, Django 1.0 will be excellent.
Good thing I'm using PHP!
gem install rails --include-dependencies
Spoon not. Fork, or fork not. There is no spoon.
I prefer developing an OO programming model abstraction and having that mapped to the database, rather than having the database introspected and then developing against the results.
This is the way most object persistence has been done for years. Yet Rails steps backwards about a decade and gets all the interest!