Rails Data Injection Vulnerability in Active Record (CVE-2014-0080)
groups.google.com
groups.google.com
The exploit is does not allow arbitrary SQL to be run (aka an attacker can't start deleting things), but it does allow data to be created/modified when it shouldn't be. Not terrifying, but a vulnerability nonetheless.
If you are running Rails 3.2 or less, or if you do not use PostgreSQL, or if you do not use Array columns, you don't need to drop everything and should simply upgrade at your leisure.
You should treat "attacker gets to modify columns of their choosing" as being epsilon away from "remote code execution." There exist multiple plausible paths to getting it which are widely implemented in Rails projects.
Two of many:
1) The attacker writes arbitrarily serialized objects into your queuing system, such as Delayed::Job. They either execute attacker-chosen instructions or the deserialization of them executes attacker-chosen instructions, in a fashion similar to the January of Fun YAML issues.
2) The attacker uses this vulnerability to compromise the admin users (and/or make their user into an admin user), thereby gaining access to your admin dashboard, and either a) causes business damage via malicious use of admin-only commands, b) achieves privilege escalation from the dashboard to e.g. an admin's email account (game over almost always), or c) they attack your app's vulnerable underbelly since who worries about a company employee exploiting appsec bugs.
It is possible that your app is resilient to these and other bugs, but until you know you are, treat this CVE as a gun pointed at your face. It may not be loaded and the trigger might not eventually be pressed, but it's still a gun pointed at your face, so prudence suggests removing the gun pointing at your face ASAP.
Rails is nowadays easily replaced. Most of the fancy server-side bits are not really that useful, and on the front-end the zeitgeist are JavaScript frameworks, where the server acts as an API but serves static HTML/JS/CSS files.
Rails regularly has security vulnerabilities reported because it's popular, mature, deployed in a lot of places, and thus gets a lot of attention. When something like Play or whatever is equivalent in the Go world is similarly exposed I would expect to see security vulnerabilities reported there, too.
Software only _gets_ widely reported CVEs if it's popular. The lack of these reports for smaller, less popular frameworks does not indicate the lack of security flaws.
Even comparing it to Go is pretty flawed, because of course Go is a language, not a framework, and it has not been tested extensively or attacked extensively, nor have the apps you have written in it. You can expect those apps to have some vulnerabilities you don't even know about as yet, unless you have had a security audit?
Like many projects, Rails is continually discovering potential security problems, though I wouldn't say it is significantly worse than other comparable frameworks/stacks, and some of the flaws they are fixing nowadays are pretty much harmless for normal use (some not, like this one, which is dangerous for the subset of users using these advanced features (probably under 5% of users)).
Pick any other widely used app framework, and you will find a similar history of security exploits discovered, though I'm sure some are better than others. It's fine to say that Rails has worse security than project x, backed up by figures, but saying anyone using Rails is shooting themselves in the foot is hyperbole.
The worst recent issue in rails I can remember is the JSON parsing incident, which also affected some python users. Just as an example comparison, in Golang if you are lazy and unmarshal into an interface or map[string]interface you might end up with similar problems of unintended data leakage, and if you unmarshal into your own struct without carefully checking what you get, you might end up with unexpected nils which only surface much later or data overwritten which was unintended. You're unlikely to get clobbered just as the Ruby JSON parser was, but you could easily introduce vulns without knowing it.
I actually prefer golang to ruby for other reasons, but the frameworks are neither mature nor battle tested, so it's not a great example to compare on security, and neither is OpenSSH.
I'm quite willing to believe that most of the golang web libraries are more solid than rails 1.0 ever was, because they were written by far more experienced programmers initially, but this is a complex topic, they do not cover everything you would need, and everyone makes mistakes. As an example, here is an exploit in play.golang.org:
http://codearcana.com/posts/2013/04/23/exploiting-a-go-binar...
You have provided no evidence that other options are significantly less vulnerable, unless you serve your web pages with OpenSSH?
My personal intuition is that Rails is insecure and becoming increasingly insecure. I have cited a high number of CVEs. If you disagree, go ahead and use Rails for your app. You'll save some time, but remember to remain vigilant about security issues.
I completely agree on speed and (perhaps more importantly) memory size, minimal golang apps far surpass rails. On security, I'm not convinced a home-grown solution in plain go or any of the extant frameworks will be significantly more secure than Rails, nor that Rails is becoming more insecure. If anything I think they're putting more effort and time into security than they did previously.
Compared to Django, a framework similar both in feature and popularity, Rails is definitely worse. Especially compared with the most serious flaws (code execution, SQL injections).
http://www.cvedetails.com/product/18211/Djangoproject-Django... http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...
Not sure about the JSON incident you mention. Maybe you thought about YAML?
I was thinking of the third one on this page (I suppose strictly speaking a vuln in a gem outside rails) which was pretty serious:
http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-Rails-3-2-12...
but there was a related YAML bug too at the same time with serialize, which also allowed users to supply input that was then instantiated (madness!). Do lots of people use serialize? I've never explicitly used it, unless it is used behind the scenes somewhere. I remembered the fuss being over JSON because of broader impact but may have misremembered.
But until then, to me, the people complaining about Rails security sound a lot like the people that complain about Windows security. When you have a product that's used by a whole lot of people, then there's going to be a lot of incentive to find security holes and a whole lot of people using the product in sometimes hard to predict ways. This does not necessarily mean that the product is inherently less secure than alternatives, it just means it's popular.
So even you know you're talking shit. Knock it off, why don't you?