Can one use Ruby $SAFE level against exploits of R

Question

Rails vulnerabilities such as CVE-2013-0155 and CVE-2013-0156 might allow a user to run arbitrary code, constructed from an untrusted source (XML/YAML parameters).

Does using $SAFE=4 (say) prevent such exploits or not? If yes, do Rails devs use such security level? If no, why?

Thanks

Answer 1

When your whole Rails has $SAFE set to 4, nothing can happen to you. Thus said, your app is crippled to deliver static views only. At least that's my experience from some time ago.

Answer 2

Tainted Objects and Protected Operations

Basically, $SAFE levels boil down to protecting an application from tainted data, but the devil is in the details. There's a whole chapter in Programming Ruby that addresses the various levels, and it's worth your time to read it over.

Rails Apps Generally Need Tainted Data

Generally speaking, the average Rails application invites tainted input. The params hash is tainted by definition, and most of your user interactions rely on tainted data. Granted that you can sanitize input or use framework features to prevent mass-assignment vulnerabilities, in most cases your application will still need to interact with user-supplied data to be truly useful.

Security Trade-Offs and Other Considerations

It may or may not be possible to run a Rails application usefully when $SAFE = 4. Quite frankly, I've never seen anyone do it with production code "in the wild." Even if you can, you will likely have to jump through so many hoops to untaint user-supplied data, instantiate ActiveRecord objects, and perform filesystem writes (e.g. logging or file uploads) that it may not be worth the security trade-offs.

You may be better served by using a lower $SAFE level and relying on other security best-practices to achieve your goals. It really just depends on what you're trying to accomplish. As with all security controls, your mileage will definitely vary.