3 ms·

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.

by 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.

by chao- 13y ago

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.