Rails SQL injection vulnerability: here are the facts(blog.phusion.nl)
blog.phusion.nl
Rails SQL injection vulnerability: here are the facts
http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/#.UOV2h_j3Giw
120 comments
This is a comment written under the confident assumption that the Phusion article is correct. I think the article is wrong, and wrong in a way that more or less invalidates this whole comment.
You should take this bug very seriously, and also pay close attention to Rails security releases for the next couple of weeks.
You should take this bug very seriously, and also pay close attention to Rails security releases for the next couple of weeks.
> I have no idea why THIS vulnerability is getting so much attention
Its getting attention because its the third SQL vulnerability in 7 months. It just feels like Rails is mature enough at this point that it shouldn't have to be going through this now
Its getting attention because its the third SQL vulnerability in 7 months. It just feels like Rails is mature enough at this point that it shouldn't have to be going through this now
It's not an "SQL injection" vulnerability; it's a logic error that happens to impact the database rather than, say, OS command execution or file handling or the object space. If you're trying to get a handle on what the actual security issues and trends are with Rails, the "SQL" in the title of this vulnerability is very misleading.
I don't see how after a project matures, there should be no exploitable bugs? Even Java still has serious bugs on a yearly basis... The only secure systems are the ones nobody uses.
ActiveRecord was basically rewritten in Rails 3 due to the introduction of ActiveRelation. That could have introduced security issues that weren't there before.
That's potentially legit (people could argue about whether these rails vulnerabilities represent something to worry about in Rails, or whether even mature robust projects will still have bugs, including security bugs).
But the fact remains that THIS vulnerability isn't NEARLY as dangerous as some of those OTHER ones you mention in the last 7 months, but those other ones people mostly ignored, and THIS one they're going crazy thinking they need to fix right away.
What I think about the general question? Most (all?) of those Rails SQL injection bugs actually are related to a similar underlying design: Attempt to create methods with 'variable signatures', where you can give it a string OR a hash, or a list of various strings and hashes, and all of those things mean different things.
I think all of the Rails SQL injection bugs are actually related to variable arguments like that. When those variable argument methods were designed in Rails, it's probably safe to say nobody realized there were security implications, that it opens you up to a whole class of bugs where someone puts a hash where you expect a string and it change the semantics of the method call because your variable argument interpreting logic had some flaws. In retrospect, it's possibly not a great thing to do.
But Rails is not the only offender here, it's a pretty common design pattern in lots of ruby -- I think it's probably a mistaken one, but it is one that developers tend to like the convenience of.
But the fact remains that THIS vulnerability isn't NEARLY as dangerous as some of those OTHER ones you mention in the last 7 months, but those other ones people mostly ignored, and THIS one they're going crazy thinking they need to fix right away.
What I think about the general question? Most (all?) of those Rails SQL injection bugs actually are related to a similar underlying design: Attempt to create methods with 'variable signatures', where you can give it a string OR a hash, or a list of various strings and hashes, and all of those things mean different things.
I think all of the Rails SQL injection bugs are actually related to variable arguments like that. When those variable argument methods were designed in Rails, it's probably safe to say nobody realized there were security implications, that it opens you up to a whole class of bugs where someone puts a hash where you expect a string and it change the semantics of the method call because your variable argument interpreting logic had some flaws. In retrospect, it's possibly not a great thing to do.
But Rails is not the only offender here, it's a pretty common design pattern in lots of ruby -- I think it's probably a mistaken one, but it is one that developers tend to like the convenience of.
I wish you'd stop telling people how dangerous you're sure this vulnerability is. I think you're probably wrong, but, more importantly, I think the only reason you're saying it is that you're echoing a meme started in an article by someone who isn't really involved in the research behind the vulnerability.
And of course, the truth of what you are saying is now evident with the vulnerabilty that 3.2.11 fixes.
What I still think this shows is that trying to keep information on the nature of the vulnerability to yourself is not a great idea. People who figured "Well, there's no way for params[:id] to be a hash with a symbol key" (such as myself) were wrong about the severity of the vulnerability.
It would have increased everyone's security to admit "Oh yeah, there might be a way to make params[:id] be a hash with symbol key even though you don't think so, yes you should worry about it."
Why not do that? Becuase you're worried you're giving someone exploitation hints, probably. But anyone that wanted to exploit had all the hints they need anyway -- as evidenced by the half dozen people credited with reporting the new vulnerability, all of whom got the hint from the 3.2.10 announcement anyway.
What I still think this shows is that trying to keep information on the nature of the vulnerability to yourself is not a great idea. People who figured "Well, there's no way for params[:id] to be a hash with a symbol key" (such as myself) were wrong about the severity of the vulnerability.
It would have increased everyone's security to admit "Oh yeah, there might be a way to make params[:id] be a hash with symbol key even though you don't think so, yes you should worry about it."
Why not do that? Becuase you're worried you're giving someone exploitation hints, probably. But anyone that wanted to exploit had all the hints they need anyway -- as evidenced by the half dozen people credited with reporting the new vulnerability, all of whom got the hint from the 3.2.10 announcement anyway.
After giving many of the comments here a thought, I've written a follow-up article "Securing the Rails session secret" in which different ways to secure the session secret are considered. Feedback is more than welcome. http://blog.phusion.nl/2013/01/04/securing-the-rails-session...
I swear I saw this same bug discussed on Reddit from some security mailing list last week, unless this is another SQL injection vulnerability with Authlogic.
You talking about this? https://github.com/binarylogic/authlogic/pull/341
It's the same thing.
It was also emailed to the Rails Core mailing list, thats where I read about it first.
The author wastes a lot of breath refuting claims that this is a huge Rails bug, then finally comes clean 3/4 of the way in:
1. http://nadiana.com/python-pickle-insecure
Other exploitable scenarios
Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be
an arbitrary user-specified hash with symbol keys.
1. http://nadiana.com/python-pickle-insecure
> The author wastes a lot of breath refuting claims that this is a huge Ruby bug
Get your facts right first. It's not a Ruby bug. It's a Rails bug. Ruby != Rails.
Many words are used to explain how it works. That is not a refute, nowhere did I claim the bug does not exist. But the requirement for specific circumstances is a fact.
The Python pickle example is not only totally irrelevant, it is also not a security vulnerability. Pickle does exactly what it is supposed to do. You weren't supposed to unpickle arbitrary untrusted data in the first place. If you require a safer alternative, use JSON or something, but don't expect as many features as pickle provides.
In the end, whether this is a "bug" or a "huge bug" is left as an opinion. The article provides hard facts, and a little bit of commentary. Fact is, we've written a ton of Rails apps that all use find_by_* quite extensively but none turned out to be vulnerable because the case where 'foo' is a symbol hash is rare. Whether you think this is an excuse or not, I'll let you decide.
Get your facts right first. It's not a Ruby bug. It's a Rails bug. Ruby != Rails.
Many words are used to explain how it works. That is not a refute, nowhere did I claim the bug does not exist. But the requirement for specific circumstances is a fact.
The Python pickle example is not only totally irrelevant, it is also not a security vulnerability. Pickle does exactly what it is supposed to do. You weren't supposed to unpickle arbitrary untrusted data in the first place. If you require a safer alternative, use JSON or something, but don't expect as many features as pickle provides.
In the end, whether this is a "bug" or a "huge bug" is left as an opinion. The article provides hard facts, and a little bit of commentary. Fact is, we've written a ton of Rails apps that all use find_by_* quite extensively but none turned out to be vulnerable because the case where 'foo' is a symbol hash is rare. Whether you think this is an excuse or not, I'll let you decide.
Thanks. Sorry, that was a freudian slip from just reading a rage tweet about Ruby vs. Rails.
Python's Pickle is insecure by design. It causes application-specific vulnerabilities the way bad crypto libraries do, by giving developers a tool to blow their feet off with. It's hard to blame Python too much for that; languages are going to provide unsafe libraries.
This, on the other hand, is just a Rails bug. It has a simple fix. That fix is provided transparently by Rails. It isn't going to cause "lots of application specific vulnerabilities" because nobody is going to care about it 6 months from now, except as yet another reason to keep Rails at the most recent version. This is a problem no different from that faced by people on J2EE stacks.
So I disagree with both of your points.
This, on the other hand, is just a Rails bug. It has a simple fix. That fix is provided transparently by Rails. It isn't going to cause "lots of application specific vulnerabilities" because nobody is going to care about it 6 months from now, except as yet another reason to keep Rails at the most recent version. This is a problem no different from that faced by people on J2EE stacks.
So I disagree with both of your points.
There should be a higher bar for libraries shipping with languages, than those shipping with frameworks like Rails.
It's not a matter of anyone egotistically "clinging" to something. The fact is that user params come in with string keys, so an app has to be doing something unusual to be vulnerable. This drastically cuts down the number of vulnerable apps. It is what it is.
The fact of the matter is people don't know enough about Rails to know what this means and like to go with the easier to spread story: "Rails vulnerability found in all versions related to user input"
Sounds much more sexy and they can do more Rails bashing that way. The fact is true as you and the article says, it's pretty obscure. In addition to being obscure, you need the secret session key.
Sounds much more sexy and they can do more Rails bashing that way. The fact is true as you and the article says, it's pretty obscure. In addition to being obscure, you need the secret session key.
There are also things a specific app could be doing that could unwittingly trigger the vulnerability as well. The core issue is worse than simply requiring the session key to be kept secret (which by itself would probably p0wn most apps much worse than the potential exploit of this vulnerability) because the dynamic finder option handling is unexpectedly a magical mine-field that no one would expect to behave that way.
So I'd characterize it as a serious problem, but not widespread in the wild, and also with some unknown risk that another major gem like AuthLogic could be as-of-now unknowingly extending the footprint of the vulnerability.
So I'd characterize it as a serious problem, but not widespread in the wild, and also with some unknown risk that another major gem like AuthLogic could be as-of-now unknowingly extending the footprint of the vulnerability.
I would love to see an example in the wild of someone taking user input, running some logic on it to create a hash with symbols and then passing it to this finder. So far noone can give an example, but Rails developers have proactively found this not very exploitable bug and patched it. Yet the attitude seems to be backwards to me. The attitude should be that an edge cause was proactively fixed and there was no known exploit of this in the wild.
I'm in agreement it's unlikely, but I think it's important to acknowledge that it's conceivable.
Yes except that bar cannot be from params since params will never return symbols as keys.
So it is pretty obscure unless you take user input and do something pretty special to make it return symbols and then run find_by_whatever on it.
So it is pretty obscure unless you take user input and do something pretty special to make it return symbols and then run find_by_whatever on it.
I don't see it as a "huge Ruby bug". Could you elaborate, please?
I would understand "huge Ruby on Rails bug", though, by convention, it is still a fairly unlikely case.
Edit: I think your edit answers my "Could you elaborate" question somewhat, as you relate a Python library issue to this issue.
I would understand "huge Ruby on Rails bug", though, by convention, it is still a fairly unlikely case.
Edit: I think your edit answers my "Could you elaborate" question somewhat, as you relate a Python library issue to this issue.
This post is written very confidently. I am less confident than the author of this post that the likelihood of a generic exploit via application input (that is, not using forged cookies) is remote.
Wish there was more I could say right now. I'm not saying I have a curl command that exploits the vulnerability. I'd just be careful about making assumptions about this bug.
Wish there was more I could say right now. I'm not saying I have a curl command that exploits the vulnerability. I'd just be careful about making assumptions about this bug.
This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them.
They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become quite apparent that Ruby code is much less maintainable, over the long term, than Java code is.
This same attitude was shown when it came to Ruby's performance. Many of us had serious misgivings about just how poorly it performed, and the suitability of Ruby on Rails for anything beyond simple sites. Then when some Ruby on Rails sites started facing moderate traffic, they basically collapsed. The answer from the Rails advocates was to "throw more hardware at it".
We even saw this same attitude when it came to this very issue. We'd heard about how Ruby on Rails is far more "secure" than alternatives. Yet that's proven not to be the case.
When Rubyists make claims, it's best to doubt what they're saying, and to question every single detail about it. They have given themselves a bad reputation for making incorrect statements.
They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become quite apparent that Ruby code is much less maintainable, over the long term, than Java code is.
This same attitude was shown when it came to Ruby's performance. Many of us had serious misgivings about just how poorly it performed, and the suitability of Ruby on Rails for anything beyond simple sites. Then when some Ruby on Rails sites started facing moderate traffic, they basically collapsed. The answer from the Rails advocates was to "throw more hardware at it".
We even saw this same attitude when it came to this very issue. We'd heard about how Ruby on Rails is far more "secure" than alternatives. Yet that's proven not to be the case.
When Rubyists make claims, it's best to doubt what they're saying, and to question every single detail about it. They have given themselves a bad reputation for making incorrect statements.
> Yet that's proven not to be the case.
> When Rubyists make claims, it's best to doubt what they're
> saying, and to question every single detail about it. They have
> given themselves a bad reputation for making incorrect
> statements.
Maybe. If so, it's only slightly more bearable than the attitude of many observers towards what or how they think "the Ruby community" collectively believe, do, or act.
There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.
There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.
No, I disagree. The Ruby community is, generally, far more cohesive and homogeneous than the others you listed. This may partly be due to it being a relatively young community, compared to some others.
Anyone who has been to a Ruby conference, especially while not being overly involved with the community otherwise, would likely know what I'm talking about, for example.
Almost the entire community is male. There are very, very, very few females involved. While other communities have an imbalance, it is nowhere near as lopsided as it is within the Ruby community.
Another common trait is the use of Apple hardware. It's rare to see anything but Apple laptops or other devices being used by those within the Ruby community. I've been at talks where there are rows of 20 people, and over 15 of them are using a MacBook of some sort.
There's very little true dissent within the community. The emphasis on "convention over configuration" ends up chiseling those conventions into stone, and nobody dares question them, even when they're obviously wrong.
While I'm not saying every single member of the Ruby community is exactly like every other, there is a commonality that is not found in any other computing community. It's undeniable.
Anyone who has been to a Ruby conference, especially while not being overly involved with the community otherwise, would likely know what I'm talking about, for example.
Almost the entire community is male. There are very, very, very few females involved. While other communities have an imbalance, it is nowhere near as lopsided as it is within the Ruby community.
Another common trait is the use of Apple hardware. It's rare to see anything but Apple laptops or other devices being used by those within the Ruby community. I've been at talks where there are rows of 20 people, and over 15 of them are using a MacBook of some sort.
There's very little true dissent within the community. The emphasis on "convention over configuration" ends up chiseling those conventions into stone, and nobody dares question them, even when they're obviously wrong.
While I'm not saying every single member of the Ruby community is exactly like every other, there is a commonality that is not found in any other computing community. It's undeniable.
I think you're conflating "the Ruby community" with "the kinds of people you see at RailsConf". Homogenous, maybe. Cohesive? Hardly.
I work with three other Ruby programmers, two of whom are female, and older than me (I'm 30). Your assertion that there are "few females involved" might as well be characterization of IT in general for all the evidence you present. In my experience diversity is a reflection of institutional values, not the culture of the programming languages used.
Apple hardware is tremendously popular with web developers in general, and while I don't blame you for your impression (I've been to RailsConf), there are plenty of Rubyists who prefer Linux on a Thinkpad. I bet you could find rich veins of Apple hardware at almost any type of conference.
There is plenty of disagreement about the best way to do things; that's why we have both Rails and Sinatra (both of which have been imitated in Python, node.js, and more) several implementations, and lots of discussions about new language features (like refinements).
I suspect your confirmation bias means you don't even notice Rubyists who don't fit your preconceptions.
I work with three other Ruby programmers, two of whom are female, and older than me (I'm 30). Your assertion that there are "few females involved" might as well be characterization of IT in general for all the evidence you present. In my experience diversity is a reflection of institutional values, not the culture of the programming languages used.
Apple hardware is tremendously popular with web developers in general, and while I don't blame you for your impression (I've been to RailsConf), there are plenty of Rubyists who prefer Linux on a Thinkpad. I bet you could find rich veins of Apple hardware at almost any type of conference.
There is plenty of disagreement about the best way to do things; that's why we have both Rails and Sinatra (both of which have been imitated in Python, node.js, and more) several implementations, and lots of discussions about new language features (like refinements).
I suspect your confirmation bias means you don't even notice Rubyists who don't fit your preconceptions.
[deleted](1)
Thank you, Peter.
I was convinced of your way of thinking, eventually ;-)
I had this exact conversation with Chad Fowler once, where I was you and he was James. Now all four of us are in agreement.
How is this not an argument against the existence of any type of "community"?
Of course there are Ruby, C and PHP communities. They do not include every single person and they can be more or less homogeneous when compared to each other.
Ask the people who are trying to build healthy communities around a new language or project if they think that these don't exist or don't matter or can't be worse or better than other communities.
Of course there are Ruby, C and PHP communities. They do not include every single person and they can be more or less homogeneous when compared to each other.
Ask the people who are trying to build healthy communities around a new language or project if they think that these don't exist or don't matter or can't be worse or better than other communities.
Well said.
It's unfair to say that the core language is flawed. Maintainability depends on how the language features are utilized. Some code uses monkey-patching gratuitously and that can harm maintainability, but judicious use of monkey patching is not a problem. On the other hand, maintaining a several gigabyte Java project can be a nightmare. Code bloat is certainly a factor here. Java is probably better for larger, more ponderous, enterprisey projects. Ruby is designed for rapid, agile development. So we don't need a "war" here; they serve different, equally important niches.
I agree that there are performance issues with Ruby implementations such as the MRI. That's really part and parcel of an immature implementation, that is, it hasn't received the millions of developer man hours spent fine-tuning it, such as the Java ecosystem has received. However, I would observe that it's still easy to get Java performance very wrong. It turns out that efficient GC is hard -- really, really hard.
I agree that there are performance issues with Ruby implementations such as the MRI. That's really part and parcel of an immature implementation, that is, it hasn't received the millions of developer man hours spent fine-tuning it, such as the Java ecosystem has received. However, I would observe that it's still easy to get Java performance very wrong. It turns out that efficient GC is hard -- really, really hard.
One man's elegance is another man's obfuscation.
How on earth is the article smug? The author responded to the controversy with clear and concise examples demonstrating that the issue is relatively minor and very easy to address if you think you are susceptible. Additionally, most people seem to be using Devise over Authlogic now-a-days. Not saying it's ok to have bugs surfaced in less popular gems, but this thing isn't going to bring the internet down.
The issue is not relatively minor, although I think the author wrote this article in good faith not realizing how non-minor it is.
It's minor because it's (apparently) already been patched and because the fix takes all of about 30 seconds to fix per instance of these types of functions. SQL injection and mass assignment issues are far more serious threats than something like this, but they are not interesting because it's on the developer to secure their app.
This issue is is built up to be serious because many people seem to enjoy attacking rails and the community despite not realizing that the vast majority of the community is amazing. If there's a burning need to criticize ruby/rails, discuss Ruby's terrible garbage collection, or the state of MRI or Rails' lightspeed rate of change.
This issue is is built up to be serious because many people seem to enjoy attacking rails and the community despite not realizing that the vast majority of the community is amazing. If there's a burning need to criticize ruby/rails, discuss Ruby's terrible garbage collection, or the state of MRI or Rails' lightspeed rate of change.
I agree that it's good that the vulnerability has a transparent framework level fix, and I myself would rather see 2-3 more framework level bugs than a whole new bug class like mass assignment. Bug classes are usually worse than bugs.
But that is not what people mean when they say this isn't a severe bug. They mean, "I read some article where some guy said you needed the right HMAC key on a cookie to exploit the bug", and I think that article is wrong, and thus the assertion about severity is wrong.
It is a severe bug with an easy fix. Unfortunately I think there are some other bugs orbiting around it that don't yet have fixes.
But that is not what people mean when they say this isn't a severe bug. They mean, "I read some article where some guy said you needed the right HMAC key on a cookie to exploit the bug", and I think that article is wrong, and thus the assertion about severity is wrong.
It is a severe bug with an easy fix. Unfortunately I think there are some other bugs orbiting around it that don't yet have fixes.
> some guy said you needed the right HMAC key on a cookie to exploit the bug
That is definitely not the intention of the article. There are other exploitable scenario and the reader is encouraged to check his code base for those instances. The article merely spends many words on what I believe would be the most scenario. The severity depends on the codebase.
That is definitely not the intention of the article. There are other exploitable scenario and the reader is encouraged to check his code base for those instances. The article merely spends many words on what I believe would be the most scenario. The severity depends on the codebase.
On this very thread you have a vulnerability researcher confirming a generic exploit of the vulnerability. Again: you're buying this article wholesale, but it's author may not know what they are talking about.
I thought the issue discovered yesterday is a totally unrelated issue than the one I described in this article. Am I mistaken?
I believe you are.
I wasn't making a language war claim. Every platform has security bugs.
Not sure where you got the idea that it's a "smug attitude". The article explains the facts and adds some commentary, nowhere did it claim that the bug does not exist or that one should not upgrade. Its intention is provide the facts and details of the exploit to counter the FUD coming from incomplete information and knee-jerk reactions. The bug is taken very seriously.
Wow, you have a serious chip on your shoulder. Nothing you're saying here is more than a gross stereotypical generalization that's no better than whatever ignorant flames you read that shaped your opinion. Are you perhaps one of the Java devs that DHH poked in the eye back in the day?
I'm surprised people are still making these arguments. Well, that's okay - don't use it then! We'll figure it out on our own.
I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?
I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?
The maintainability criticism is nothing new, or unique to Ruby — it has been something that has been leveled at every dynamically-typed language (eg., Python, Perl) ever since they started to become popular for writing big apps. And it's still untrue.
It comes from prejudice and fear about the lack of compile-time checks in dynamic languages. I know this personally, because I remember starting out with Python, and Java and C++ felt very safe — on a visceral level — in comparison, and Python felt very unsafe. I have since learned to recognize these feelings as irrational and unfounded.
Any language allows you to shoot yourself in the foot, in different ways. It's just as easy to write an unmaintainable app in C++ as it is in Ruby.
It comes from prejudice and fear about the lack of compile-time checks in dynamic languages. I know this personally, because I remember starting out with Python, and Java and C++ felt very safe — on a visceral level — in comparison, and Python felt very unsafe. I have since learned to recognize these feelings as irrational and unfounded.
Any language allows you to shoot yourself in the foot, in different ways. It's just as easy to write an unmaintainable app in C++ as it is in Ruby.
It all depends on the writing style of the app. If someone writes the entire app as learning exercise in metaprogramming, then I am guessing it will be a nightmare to maintain.
The attitude within your first paragraph is an excellent demonstration of the maintainability problems I'm talking about. Programmers five or ten years in the future won't have much say about the software they're being asked or told to maintain. Telling them to just "not use Ruby" won't solve the maintenance issues they're facing while working on some Rails web app developed years earlier.
I'm sure you can find numerous blog posts out there describing the maintainability problems with Rails web apps. Google for them. The fact that you're looking for blog articles makes me think that you may have limited experience with large-scale software development projects, especially those spanning many years and development teams.
Have you ever worked on large, long-running C++ or Java projects, for instance? If you have, then it should be pretty obvious to you how inadequate the maintainability of Ruby code is. Ruby, and dynamic languages in general, lack much of the functionality that makes code maintainable after many years, or even decades. I really wish you did have this sort of experience, because I think it would make the maintenance issues more more obvious.
I'm sure you can find numerous blog posts out there describing the maintainability problems with Rails web apps. Google for them. The fact that you're looking for blog articles makes me think that you may have limited experience with large-scale software development projects, especially those spanning many years and development teams.
Have you ever worked on large, long-running C++ or Java projects, for instance? If you have, then it should be pretty obvious to you how inadequate the maintainability of Ruby code is. Ruby, and dynamic languages in general, lack much of the functionality that makes code maintainable after many years, or even decades. I really wish you did have this sort of experience, because I think it would make the maintenance issues more more obvious.
I'm asking you to explain why any of it is an issue, and to back it up with the comments of other people.
I want to see people who have written "the fact that this project is in Ruby is the bane of my existence and here is why these problems would not have occurred in my language of choice".
>lack much of the functionality that makes code maintainable after many years, or even decades.
This is just FUD. LOL, what inherent property is this that makes it maintainable?
Great trolling, btw.
I want to see people who have written "the fact that this project is in Ruby is the bane of my existence and here is why these problems would not have occurred in my language of choice".
>lack much of the functionality that makes code maintainable after many years, or even decades.
This is just FUD. LOL, what inherent property is this that makes it maintainable?
Great trolling, btw.
[deleted]
Our Rails site successfully served 45k simultaneous requests for the National Moment of Silence two weeks ago. I call that moderate traffic, and we didn't fall over. Please stop assuming that no one can make Rails scale just because there are some popular stories of it not scaling.
What kind of hosting infrastructure was involved?
You're only looking at part of the picture, I think. It's not just a matter of asking, "will the site hold up?", but rather it's one of "will the site hold up, given an economically-feasible amount of resources?"
Throwing a lot of resources at a Ruby on Rails site for one day of heavy traffic is one thing. Having to do that for years on end just to maintain a reasonable level of service in the face of growth is a very different thing, and far closer to the reality that we have to deal with.
You're only looking at part of the picture, I think. It's not just a matter of asking, "will the site hold up?", but rather it's one of "will the site hold up, given an economically-feasible amount of resources?"
Throwing a lot of resources at a Ruby on Rails site for one day of heavy traffic is one thing. Having to do that for years on end just to maintain a reasonable level of service in the face of growth is a very different thing, and far closer to the reality that we have to deal with.
Colo with 17 app servers. We didn't have to spin up additional workers, and this is about half the number of web servers the last startup-turn-IPO I worked at used (and they used Python!).
2647 connections per server per second is pretty abysmal for modern server hardware, especially if you had to rely on a whole bunch of caching front-end complication and proxy web servers to make it happen.
You can't say that without knowing what the app does.
A recent project that I've been involved with switch from Java to Ruby and they reduced the number of servers by 10 times (!). But I don't blame Java, I blame the programmers of the last code base. You can write unmaintainable messes in any language.
A recent project that I've been involved with switch from Java to Ruby and they reduced the number of servers by 10 times (!). But I don't blame Java, I blame the programmers of the last code base. You can write unmaintainable messes in any language.
Were the exact same servers reused?
I once interviewed a Rails developer who was bragging about a Java-to-Ruby conversion he'd worked on. He was proud that they went from 50 servers running the Java system to only 30 for the Ruby one.
Upon further questioning, he admitted that those 50 servers used by the Java system were from 2003, and the ones powering the Ruby-based system were from 2011! They didn't even halve the number of servers required, but the new servers were many, many times more powerful than the old ones.
I once interviewed a Rails developer who was bragging about a Java-to-Ruby conversion he'd worked on. He was proud that they went from 50 servers running the Java system to only 30 for the Ruby one.
Upon further questioning, he admitted that those 50 servers used by the Java system were from 2003, and the ones powering the Ruby-based system were from 2011! They didn't even halve the number of servers required, but the new servers were many, many times more powerful than the old ones.
[deleted](2)
yeah well, tell you what. 70% of what i saw since coming to the us are enterprise .net applications(yeah, i'm not in silicon valley or nyc). the other 20% were dated oracle applications.
The security practices i saw are nothing short of ridiculous. If you'd take all the rails vulnerabilities and put them in a pot, and compare them to the holes i've seen in the little time i looked at them it's like comparing a secure vault to swiss cheese.
granted, saying x is secure, because y is inherently insecure is not a valid argument, but i've seen people first hand use these exaggerated advisories to justify that their bug ridden insecure enterprise stack is more justifiable for the enterprise. these people did not know pbkdf2, bcrypt, and even the sql injection whitepaper by microsoft(which btw is a joke).
wanna write secure code? NEVER assume someone else is going to secure it to you. fact is, good advisories and quick reaction to those are not a weakness but a strength.
You want to know the state of encryption in the enterprise world? Get a recent pastebin hack dump. Databases with passwords in plaintext, passwords in md5.
as for your sites basically collapsed? yes they did, it got popular during ruby 1.8.5 ffs. what the hell do you expect? it's slow? well, that's why theres lot's of custom c around. but anyway, since then many many things changed.
Java maintainable? In which world do you live? 8 different layers of OO abstractions 20 levels of dot notation, in which world is that maintainable? Notice how people move to groovy, scala, and other things, not plain java? ever wondered why?
You want highly reliable systems, your answer is not going to be java. Try erlang, but that one is GENUINELY slow.
Oh wait, did I even mention jruby? There you go, all the Java you want, kinda.
The security practices i saw are nothing short of ridiculous. If you'd take all the rails vulnerabilities and put them in a pot, and compare them to the holes i've seen in the little time i looked at them it's like comparing a secure vault to swiss cheese.
granted, saying x is secure, because y is inherently insecure is not a valid argument, but i've seen people first hand use these exaggerated advisories to justify that their bug ridden insecure enterprise stack is more justifiable for the enterprise. these people did not know pbkdf2, bcrypt, and even the sql injection whitepaper by microsoft(which btw is a joke).
wanna write secure code? NEVER assume someone else is going to secure it to you. fact is, good advisories and quick reaction to those are not a weakness but a strength.
You want to know the state of encryption in the enterprise world? Get a recent pastebin hack dump. Databases with passwords in plaintext, passwords in md5.
as for your sites basically collapsed? yes they did, it got popular during ruby 1.8.5 ffs. what the hell do you expect? it's slow? well, that's why theres lot's of custom c around. but anyway, since then many many things changed.
Java maintainable? In which world do you live? 8 different layers of OO abstractions 20 levels of dot notation, in which world is that maintainable? Notice how people move to groovy, scala, and other things, not plain java? ever wondered why?
You want highly reliable systems, your answer is not going to be java. Try erlang, but that one is GENUINELY slow.
Oh wait, did I even mention jruby? There you go, all the Java you want, kinda.
As a developer it is best to enable yourself to collect some relevant facts about technical questions and come to a decision based on that data.
Basing an argument about technical things on "what people say" will not succeed, no matter what your goals are.
Basing an argument about technical things on "what people say" will not succeed, no matter what your goals are.
Not disagreeing with you there. After all there's no way to prove that something doesn't exist. What's why I wrote that everyone should upgrade, just in case. :)
The goal of the article is not to defend Rails. It is to inform about the nature of the vulnerability and to replace the feeling of panic with rational thoughts.
The goal of the article is not to defend Rails. It is to inform about the nature of the vulnerability and to replace the feeling of panic with rational thoughts.
I'm not quite sure what you're hinting at. I know there's been found a DoS-exploit related to the parameter handling (expect a new security release soon), but at least it seems to be safe to say that this bug can't be triggered from `params`.
I can confirm that there is a generic way to exploit this. There is also a denial of service vector that is currently unpatched and depending on the way you have written your app there is a remote code execution issue as well which is unpatched (i don't think any real apps would be vulnerable to this.. but who knows). i suspect dos + rce use the same vector that tptacek has found.
There are a bit more vulns hanging around 'params' http://homakov.blogspot.com/2013/01/rails-security-digest-el...
So you don't have a curl command that exploits it, but you don't believe the authors. That leaves us with what?
Apparently, it leaves you waiting for an upcoming Rails advisory.
Apparently some people don't like Rails and love to see an obscure bug that requires the secret session key, therefore they think their cherished and strongly held dislike will finally bask in smug glory.
Edit: I shouldn't have been so harsh since the author is a security researcher and is probably not doing it out of some grudge. But even from a security researcher, saying he has doubts about a software doesn't make something insecure.
If he can prove his statement that he thinks regular user input is insecure (without requiring the secret session key), then I will happily be convinced of his prowess in finding exploits.
Edit: I shouldn't have been so harsh since the author is a security researcher and is probably not doing it out of some grudge. But even from a security researcher, saying he has doubts about a software doesn't make something insecure.
If he can prove his statement that he thinks regular user input is insecure (without requiring the secret session key), then I will happily be convinced of his prowess in finding exploits.
I can confirm that @charliesome has found a loop-hole in Rails' parameters processing that makes it possible to do some really nasty stuff. I also know that other have discovered the same bug independently. I don't think anything has leaked to the public yet.
Based on Charlie's PoC I managed to sneak a SQL-injection into some really basic ActiveRecord queries. It's not entirely obvious how to accomplish this, but it wouldn't surprise me if other people who discovered the same bug will find similar exploits.
This has been reported to Rails' security team and I expect patches to be released pretty soon.
For now I don't have an easy-to-apply workaround that doesn't disclose the gist of the exploit.
Based on Charlie's PoC I managed to sneak a SQL-injection into some really basic ActiveRecord queries. It's not entirely obvious how to accomplish this, but it wouldn't surprise me if other people who discovered the same bug will find similar exploits.
This has been reported to Rails' security team and I expect patches to be released pretty soon.
For now I don't have an easy-to-apply workaround that doesn't disclose the gist of the exploit.
I think we are talking about two different conditions. Wee!
I'm a full time rails developer and member of the "ruby community" and have nothing against rails. I am also strongly inclined to take tptacek at his word when he speaks on issues of security, even if he's light on the details. It's quite literally free consulting.
EDIT in response to upsteam edit: He did imply that you should wait for the upcoming Rails advisory, so you'll get your proof then.
EDIT in response to upsteam edit: He did imply that you should wait for the upcoming Rails advisory, so you'll get your proof then.
Well I should apologize, i didn't realize the comments were from a seasoned security researcher. I don't know the first thing about vulnerability testing, I just make reasonable precautions in code that I write. If you and others have spent time doing actual vulnerability testing, then I have to defer.
This leaves us with assuming that remotely triggered bugs can be exploited until proven otherwise, the way a sane person would.
The post states that it is not exploitable through user input via params. They could show you the source code, but I don't know if that would be proof for you. You said that you are assuming it can be exploited, so someone should show it.
Respectfully, what do I care what the author thinks of this vulnerability? Even if they had found the SQLI condition originally (they didn't), that wouldn't mean they fully understood the exposure.
Meet the new boss, same as the old one...
This bug is pretty edge, but if there was an easy way for a user to put a symbol in the params hash the bug would be a pretty gnarly universal SQL injection vulnerability for all versions of Rails.
Though if that was easy it would most likely have been caught much, much earlier as there are a multitude of find helpers that allow literal SQL to be injected.
Though if that was easy it would most likely have been caught much, much earlier as there are a multitude of find helpers that allow literal SQL to be injected.
Early versions of Rails explicitly made the decision to never symbolize user inputted hashes because symbols are never garbage collected. This would allow memory to grow unbounded. As a result Rails stores all user hash keys as strings.
There are suggestions that it is possible (potentially easy) for a user to get symbols into the params hash.
If you are scanning your code base for find_by_'s, make sure to look at your find_all_by_'s as well if you have them.
...and while you're at it, rewrite those into some other form. Everything but the find_by_* dynamic finders is going to be deprecated soon anyways.
http://edgeguides.rubyonrails.org/4_0_release_notes.html#ext...
http://edgeguides.rubyonrails.org/4_0_release_notes.html#ext...
If I understand this correctly, given that a private key is needed to successfully modify the signed HTTP cookie, for a closed-source project using Ruby, Rails, and Authlogic, this vulnerability might be better characterized as an "unintentional backdoor."
Yep, but even if you have a closed-source project you should avoid checking in any secret keys or other credentials to your source control system.
I wish ruby had named the Hash class properly. It makes reading the article slightly confusing. Hash != Hashtable
You can blame Perl for that. Ruby took "Hash" from Perl's name for its native hash tables.
Of course the Hash class in Ruby implements a hash table. What makes you think it doesn't?
I believe that macca321 is wishing that, to avoid confusion, the term "hash" was reserved for referring to an individual hash code and that "hash table" was used for the data structure and the Ruby class that implements it.
I'm starting to wonder if the DRY-uber-alles notion popularized by Rails is turning into a security antipattern. It's just too easy for code like this (intended to "make things work cleanly") to forget all the needed checks and all the constraints on the design.
The end user ends up repeating themselves less, but that means that the library code ends up getting used in lots of places and for lots of purposes that the author didn't necessarily think through...
The end user ends up repeating themselves less, but that means that the library code ends up getting used in lots of places and for lots of purposes that the author didn't necessarily think through...
The vulnerability here was caused by deliberately introduced complexity --- features for features sake. You're tempted to blame the dynamic finders (which have fallen far out of fashion anyways) but really the issue here is Rails parameter handling, which was not designed to minimize typing for Ruby programmers.
It also means that when a bug is found in that code that you only have to fix it in one place, not 75,000 random places where it's duplicated, and probably slightly differently each time, making it hard to search for.
That seems to be belied by this very case, no? Rails had two ways of doing something, one of which forgot where the input could come from...
Hmm... How would copy-pasta code have prevented this?
I fear from your language that you aren't really interested in reasonable argument, but I'll try anyway: ActiveRecord had two variant find() interfaces, one of which tried to make it "easy" on the programmer by avoiding the need to extract an ID to do the lookup. And it went further by adding an overloaded argument syntax that allowed you to elide the first argument entirely. And it forgot that that second argument simultaneously (1) was defined by a remote client and (2) could contain arbitrary SQL.
So yes: "copy pasta" of the id boilerplate around an AR find() call would absolutely have prevented this. Rails got slick, and got burned. DRY helped reduce "copy pasta" (sigh) but hurt security.
So yes: "copy pasta" of the id boilerplate around an AR find() call would absolutely have prevented this. Rails got slick, and got burned. DRY helped reduce "copy pasta" (sigh) but hurt security.
Isn't that really the fault of an overloaded (as in doing too much) function API rather than a DRY related problem?
Well, yes, but my point was that I see them as part of the same thing. A function (or whatever) that does lots of related things can be "DRY" if it avoids writing out all the related things longhand, or it can be "too much" if it introduces bugs.
DRY as a general philosophy to avoid cut-and-paste code is fine. But it's also an ethic that in my experience prioritizes concision at the expense of clarity. Loss of clarity is a factor in half the security bugs on the internet.
DRY as a general philosophy to avoid cut-and-paste code is fine. But it's also an ethic that in my experience prioritizes concision at the expense of clarity. Loss of clarity is a factor in half the security bugs on the internet.
the other thing to note is that if your application is deserializing untrusted input using Marshall.load and calling methods on the deserialized objects then there is a chance that you are vulnerable to arbitrary ruby code execution. in that case an attacker could execute whatever sql he wanted to anyway.
Excellent post - clear and with example.
But - I'm confused why one of the readers on the post (Jonas) is calling this a PR Stunt?
But - I'm confused why one of the readers on the post (Jonas) is calling this a PR Stunt?
I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention.
The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just led to the current hysteria instead. They would have been better off being taking the extra time to be fully transparent about the nature of the vulnerability -- developers need to know to assess their own risk, as well as to judge the quality of Rails (how stupid was the problem exactly, what does it say about Rails etc?), etc. By being vague about it, Rails core team has just led to everyone assuming the worst, and the current weird hysteria.
Yes, it's a vulnerability which COULD be dangerous, and it's hard to tell FOR SURE if your app is vulnerable (perhaps due to code in gem dependencies), the only safe thing to do is update to a patched version. But the chances that your app is vulnerable are pretty small (if you aren't using AuthLogic; if you are, you can update auth_logic and fix it whether or not you update rails). And past recent vulnerabilities which were actually MORE dangerous have not received this level of attention.