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.
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.
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?
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.
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 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 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.
> 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.
There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Basing an argument about technical things on "what people say" will not succeed, no matter what your goals are.
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.
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 in response to upsteam edit: He did imply that you should wait for the upcoming Rails advisory, so you'll get your proof then.
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.