3 ms·

You should mention that this will give false negatives for people who actually are vulnerable but happen to be running Ruby 1.8.7, by the way. (I'm distilling

by patio11 14y ago

You should mention that this will give false negatives for people who actually are vulnerable but happen to be running Ruby 1.8.7, by the way. (I'm distilling that from this part of the announcement blog post, plus the knowledge that Syck is the default 1.8.X parser. It is indeed difficult to exploit -- I banged my head into a wall for 12 hours attempting to do so -- but people who are highly credible to me on this issue report having successful exploits for it.) Also, this check is for websites using the Psych YAML Engine and not the older Syck. All of the proof of concepts we've seen so far are for Psych. That doesn't mean Syck isn't vulnerable, but that our checker will only work for Psych. In all likelihood, Syck is vulnerable too and you should upgrade your Rails all the same.

borski 14y ago
Thanks. Yeah, we have some friends who have some working sploits for it now too. We'll work that in.
JangoSteve 14y ago
The exploit gist was actually pretty easy to modify in order to correctly identify if a Rails 2.3.x / Ruby 1.8.7 app was vulnerable. If you accept the fact that "payload being interpreted as object deserialized from YAML" is bad, then you don't necessarily need a malicious object to see if your app is vulnerable. If you have access to your Rails logs, then you just need to see a params value in your logs that's an object. Here is my modified gist that can help you identify if your app is vulnerable, which works with Rails 2.3.x / Ruby 1.8.7 apps. If you run this and see in your Rails log something like "params = {#<ActionController... => {default => :action}...}", then your app is vulnerable: https://gist.github.com/4694948/26d9b6d46c2c60aeb5abde9ca2c2154a5816968e https://gist.github.com/4694948/26d9b6d46c2c60aeb5abde9ca2c2... We also have a couple apps we know of that are really old Rails 2.2.x apps. This doesn't work with them, because the passed YAML doesn't work in the old YAML parser. But then, if you just trust that deserializing an object from YAML in parameters is bad, then we can just make a super simple hash object and check our rails logs to see if the params contain an actual hash object. Here's an even-more-simplified-harmless proof-of-concept to test older Rails 2.2.x apps: https://gist.github.com/4694948/1e8a94f7c768bf958632880050399904defba531 https://gist.github.com/4694948/1e8a94f7c768bf95863288005039... I'm no security expert, but I was able to use these PoCs last night to verify that the patch for Rails 2.3.x worked, and also that my reverse-engineered-patch for Rails 2.2.x worked as well. Edit: Just to clarify and reiterate, the above modified PoCs require access to the Rails app logs to check if they worked or not, since the older Rails apps could error out for YAML-parsing reasons (which are just as bad, because it just means an attacker needs to get more creative with their YAML payload), instead of being a result of rejecting the attack. That's why I don't think a web-based attack mechanism like this could really know 100% whether or not an app is vulnerable unless it really tried doing something semi-malicious, like obtaining secret information.
- borski 14y ago
  You're completely right. We call out that it isn't 100% certain if we return a 'not vulnerable'. Our full scan will soon include some code execution modules for these vulnerabilities which will provide a more certain response.

by patio11 14y ago

borski 14y ago

Thanks. Yeah, we have some friends who have some working sploits for it now too. We'll work that in.

JangoSteve 14y ago

The exploit gist was actually pretty easy to modify in order to correctly identify if a Rails 2.3.x / Ruby 1.8.7 app was vulnerable. If you accept the fact that "payload being interpreted as object deserialized from YAML" is bad, then you don't necessarily need a malicious object to see if your app is vulnerable. If you have access to your Rails logs, then you just need to see a params value in your logs that's an object. Here is my modified gist that can help you identify if your app is vulnerable, which works with Rails 2.3.x / Ruby 1.8.7 apps. If you run this and see in your Rails log something like "params = {#<ActionController... => {default => :action}...}", then your app is vulnerable: https://gist.github.com/4694948/26d9b6d46c2c60aeb5abde9ca2c2154a5816968e https://gist.github.com/4694948/26d9b6d46c2c60aeb5abde9ca2c2... We also have a couple apps we know of that are really old Rails 2.2.x apps. This doesn't work with them, because the passed YAML doesn't work in the old YAML parser. But then, if you just trust that deserializing an object from YAML in parameters is bad, then we can just make a super simple hash object and check our rails logs to see if the params contain an actual hash object. Here's an even-more-simplified-harmless proof-of-concept to test older Rails 2.2.x apps: https://gist.github.com/4694948/1e8a94f7c768bf958632880050399904defba531 https://gist.github.com/4694948/1e8a94f7c768bf95863288005039... I'm no security expert, but I was able to use these PoCs last night to verify that the patch for Rails 2.3.x worked, and also that my reverse-engineered-patch for Rails 2.2.x worked as well. Edit: Just to clarify and reiterate, the above modified PoCs require access to the Rails app logs to check if they worked or not, since the older Rails apps could error out for YAML-parsing reasons (which are just as bad, because it just means an attacker needs to get more creative with their YAML payload), instead of being a result of rejecting the attack. That's why I don't think a web-based attack mechanism like this could really know 100% whether or not an app is vulnerable unless it really tried doing something semi-malicious, like obtaining secret information.

borski 14y ago
You're completely right. We call out that it isn't 100% certain if we return a 'not vulnerable'. Our full scan will soon include some code execution modules for these vulnerabilities which will provide a more certain response.