To All Rails Developers: SQL Injection Flaw Haunts All Ruby on Rails Versions

[jimbobway]

Rails seems to be a popular development language for bitcoin.  I think I've been hearing some sql injection attacks lately on some bitcoin websites but here is a story on it.  (I've been accused of being a troll here for talking negatively on rails before):

All of the current versions of the Ruby on Rails Web framework have a SQL injection vulnerability that could allow an attacker to inject code into Web applications. The vulnerability is a serious one given the widespread use of the popular framework for developing Web apps, and the maintainers of Ruby on Rails have released new versions that fixes the flaw, versions 3.2.10, 3.1.9 and 3.0.18.

https://threatpost.com/en_us/blogs/sql-injection-flaw-haunts-all-ruby-rails-versions-010313

Mod: Move this to Project Development.  I put it in the wrong forum.

[1713879046]

1713879046

[1713879046]

1713879046

[davout]

CVE-2012-5664 for the record

[dust]

Bumping with another critical vulnerability. Upgrade immediately!

https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ

[davout]

Bumping with another critical vulnerability. Upgrade immediately!

https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ

This one is CVE-2013-0155

Only applications that accept XML parameters are vulnerable

[notme]

Don't use deprecated methods!

[davout]

Don't use deprecated methods!

What ?

[notme]

Don't use deprecated methods!

What ?

Maybe they aren't officially deprecated, but the find_by_* methods are old the old style finders.  Regardless, leaving the "secret key" in a public repo is just fail anyway.

[davout]

Maybe they aren't officially deprecated, but the find_by_* methods are old the old style finders.

find_by_* finders are fine. Also you're mixing up the two vulnerabilities.

Regardless, leaving the "secret key" in a public repo is just fail anyway.

What are you even talking about here ?

[notme]

I mean the find_by vulnerability is only exploitable if you know the HMAC key for the application that should be kept secret.

[dust]

Bumping with another critical vulnerability. Upgrade immediately!

https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ

This one is CVE-2013-0155

Only applications that accept XML parameters are vulnerable

It is my understanding that all unpatched rails apps are potentially vulnerable, regardless of their use of XML.  One of the suggested workarounds if XML parsing was not needed was to disable it in the config.  CVE-2013-0155 is much more severe than the one in the OP (CVE-2012-5664).

Edit: Yep, serious business.

[davout]

It is my understanding that all unpatched rails apps are potentially vulnerable, regardless of their use of XML.  One of the suggested workarounds if XML parsing was not needed was to disable it in the config.  CVE-2013-0155 is much more severe than the one in the OP (CVE-2012-5664).

Edit: Yep, serious business.

Yea, pretty much all Rails apps will accept XML params by default.
Both seem quite severe and I think everyone using Rails should just religiously apply the fixes (which are trivial btw)

Apparently I made it sound like I didn't feel concerned about it, but that's not the case, Instawallet, Instawire and Bitcoin-Central were immediately patched when I received Aaron Patterson's e-mails through the Rails security mailing list (which I encourage every Rails developer around here to subscribe to).

[molecular]

Maybe they aren't officially deprecated, but the find_by_* methods are old the old style finders.

find_by_* finders are fine. Also you're mixing up the two vulnerabilities.

Regardless, leaving the "secret key" in a public repo is just fail anyway.

What are you even talking about here ?

"The Rails session mechanism allows storing arbitrary Ruby objects, including hashes with symbol keys. Rails provides a variety of session stores, the default being the cookie store which stores session data in a cookie on the client. The cookie data is not encrypted, but is signed with an HMAC [hash-based message authentication cookie] to prevent tampering. The cookie store is fast, does not require any server-side maintenance, and is only meant for session data that do not contain sensitive information such as credit card numbers. Apps that store sensitive information in the session should use the database session store instead. Nevertheless, it turned out that 95% of all Rails apps only ever store the user authentication credentials in the session, so the cookie store was made the default," Hongli Lai of Phusion wrote in an analysis of the problem.

"So to inject arbitrary SQL, you need to tamper with the cookie, which requires the HMAC key. The HMAC key is the so-called session secret. As the name implies, it is supposed to be secret. Rails generates a random 512-bit secret upon project creation. This is why most Rails apps that are running Authlogic are not exploitable: the attacker does not know the secret. Open source Rails apps however can form a problem. Many of them come with a default session secret, but the user never customizes them, so all those instances end up using the same HMAC key, making them very easily exploitable. Of course, in this case the operator have to worry about more than just SQL injection. If the HMAC key is known then anybody can send fake credentials to the app."

how many different vulnerabilities is the article actually talking about?

[davout]

how many different vulnerabilities is the article actually talking about?

If someone knows the HMAC secret and you're using cookie store someone can mess with the data in it, that's a feature.
The vulnerabillity is that it could be used as a vector to exploit an SQL injection vulnerability (didn't read the details, just religiously applied the fixes).

I recommend against using cookie store anyway and switch to Redis/Memcached/ActiveRecord for storing session data.

[Mike Hearn]

It's also possible to run arbitrary Ruby (and thus commands) on the server, take a look at the metasploit module, thanks to the YAML integration.

It's really very serious and leads to complete compromise. It makes me wonder how long blackhats have known about that.

[BasementMiner!]

It's also possible to run arbitrary Ruby (and thus commands) on the server, take a look at the metasploit module, thanks to the YAML integration.

It's really very serious and leads to complete compromise. It makes me wonder how long blackhats have known about that.

While this vulnerability is just as serious, its not related to the one mentioned by OP.

[kiba]

Rails seems to be a popular development language for bitcoin.

Sir, rails is not a language. It is a framework.

[jimbobway]

Rails seems to be a popular development language for bitcoin.

Sir, rails is not a language. It is a framework.

My mistake.  I keep on making it.

[whizter]

This exploit is already being used, bitoins were stolen from Vircurex and Cryptostocks according to http://www.heise.de/newsticker/meldung/Diebe-stehlen-Bitcoins-per-Rails-Exploit-1782688.html

[jimbobway]

Another exploit: CVE-2013-0333

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0333

lib/active_support/json/backends/yaml.rb in Ruby on Rails 2.3.x before 2.3.16 and 3.0.x before 3.0.20 does not properly convert JSON data to YAML data for processing by a YAML parser, which allows remote attackers to execute arbitrary code, conduct SQL injection attacks, or bypass authentication via crafted data that triggers unsafe decoding, a different vulnerability than CVE-2013-0156.

Known Ruby exchanges:  bitcoin-central.net, vircurex?, coinbase

[davout]

Another exploit: CVE-2013-0333

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0333

lib/active_support/json/backends/yaml.rb in Ruby on Rails 2.3.x before 2.3.16 and 3.0.x before 3.0.20 does not properly convert JSON data to YAML data for processing by a YAML parser, which allows remote attackers to execute arbitrary code, conduct SQL injection attacks, or bypass authentication via crafted data that triggers unsafe decoding, a different vulnerability than CVE-2013-0156.

Known Ruby exchanges:  bitcoin-central.net, vircurex?, coinbase

FTR Rails 3.2.x series isn't affected.