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.
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.
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.
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
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
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.
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.