8 ms·

Someone explain this to be like I'm 5?

chao- 13y ago
If you are running Rails 4.0.0, 4.0.1, 4.0.2 or 4.1.0.beta1, AND you use PostgreSQL AND you use Array columns therein, then you are affected. Upgrade ASAP to 4.0.3 or 4.1.0.beta2. 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.
- patio11 13y ago
  You're substantially right with who isn't affected, but I would recommend prioritizing this as Immediate Remediation Required if any part of your app is affected. 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.
hfghegheotqhgo 13y ago
Bad framework, with too much magic, poor security, poor performance, not good for anything beyond the five minute blog.
- kordless 13y ago
  You are indirectly blaming a WHOLE LOTTA people with this comment. Learn to play nicely with others and maybe someone will listen to your complaints. Chances are, you don't care. <---- that's a blaming statement.
- vesinisa 13y ago
  Sadly, I tend to agree. It seems anyone starting a new publicly-accessible web site with Rails are aiming for a shot at their own feet. Rails might still be usable for Intranet servers in a trusted network setting or prototyping web site ideas before transitioning to a "serious" framework. The continuing security issues and lack of focus on performance make it terrible choice for any production web site.
  - matthewmacleod 13y ago
    With respect, you don't know what the hell you are talking about. All software suffers from security issues, and Rails' performance issues are overstated.
    - vesinisa 13y ago
      Rails does suffer disproportionately from security issues. The framework code has become increasingly bloated and serious security vulnerabilities are being continuously discovered (see http://www.cvedetails.com/vulnerability-list/vendor_id-12043/product_id-22568/Rubyonrails-Ruby-On-Rails.html http://www.cvedetails.com/vulnerability-list/vendor_id-12043...) both on the low and high level code (the seriousness of this specific vulnerability depends on application). While I like Rails, I would not choose it as a server-side framework for my product anymore: painful to maintain (backwards-compatibility is not a priority) and slow (compared to say, Go, anyway). 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.

chao- 13y ago

If you are running Rails 4.0.0, 4.0.1, 4.0.2 or 4.1.0.beta1, AND you use PostgreSQL AND you use Array columns therein, then you are affected. Upgrade ASAP to 4.0.3 or 4.1.0.beta2. 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.

patio11 13y ago
You're substantially right with who isn't affected, but I would recommend prioritizing this as Immediate Remediation Required if any part of your app is affected. 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.

hfghegheotqhgo 13y ago

Bad framework, with too much magic, poor security, poor performance, not good for anything beyond the five minute blog.

kordless 13y ago
You are indirectly blaming a WHOLE LOTTA people with this comment. Learn to play nicely with others and maybe someone will listen to your complaints. Chances are, you don't care. <---- that's a blaming statement.
vesinisa 13y ago
Sadly, I tend to agree. It seems anyone starting a new publicly-accessible web site with Rails are aiming for a shot at their own feet. Rails might still be usable for Intranet servers in a trusted network setting or prototyping web site ideas before transitioning to a "serious" framework. The continuing security issues and lack of focus on performance make it terrible choice for any production web site.
- matthewmacleod 13y ago
  With respect, you don't know what the hell you are talking about. All software suffers from security issues, and Rails' performance issues are overstated.
  - vesinisa 13y ago
    Rails does suffer disproportionately from security issues. The framework code has become increasingly bloated and serious security vulnerabilities are being continuously discovered (see http://www.cvedetails.com/vulnerability-list/vendor_id-12043/product_id-22568/Rubyonrails-Ruby-On-Rails.html http://www.cvedetails.com/vulnerability-list/vendor_id-12043...) both on the low and high level code (the seriousness of this specific vulnerability depends on application). While I like Rails, I would not choose it as a server-side framework for my product anymore: painful to maintain (backwards-compatibility is not a priority) and slow (compared to say, Go, anyway). 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.