Home/ Questions/Q 1016605
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T10:34:26+00:00

Ruby’s safe mode disallows the use of tainted data by potentially dangerous operations. It

  • 0

Ruby’s safe mode disallows the use of tainted data by potentially dangerous operations. It varies in levels, 0 being disabled, and then 1-4 for levels of security. What vulnerabilities are possible when safe mode is enabled? Do you know of any CVE numbers issued to a ruby program when safe mode is enabled? What CWE Violations (or cwe families) are possible with safe mode enabled?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    All application-level vulnerabilities are completely unaffected by the $SAFE level. Injection attacks that don’t pass through an “unsafe operation” like cross-site scripting and SQL injection for example. This includes, more or less, every vulnerability class for web applications, except perhaps local and remote file inclusion. See the OWASP Top 10, $SAFE doesn’t help with many of these.

    The $SAFE level does protect you somewhat against system-level vulnerabilities though. If an attacker is able to write Ruby code into a file in /tmp, they wouldn’t then be able to trick your program into loading that code if $SAFE >= 2.

    And this of course doesn’t include any vulnerabilities with Ruby itself. These are much more serious, and can bypass $SAFE entirely.

    Or plain old buffer overflows, integer overflows, etc in the Ruby interpreter itself that have nothing to do with $SAFE.

    Rails has a history vulnerabilities that occur whether $SAFE is enabled or not. This is complicated by the fact that user input is stored in Rails applications, and malicious data can pop back up at a later time.

    Vulnerability reports in Ruby applications other than Rails and MRI are hard to come by.

    Another big problem with $SAFE is there is no real list (that I know of) that outlines exactly what $SAFE does and doesn’t protect. About the only thing you can do is search for ruby_safe_level in eval.c (this is an older eval.c from 1.8.4). The comments provide this description, but it’s pretty vague.

    /* safe-level:
   0 - strings from streams/environment/ARGV are tainted (default)
   1 - no dangerous operation by tainted value
   2 - process/file operations prohibited
   3 - all generated objects are tainted
   4 - no global (non-tainted) variable modification/no direct output
*/

    I guess what I’m trying to say is that $SAFE is all about system security. It does an OK job, but there’s no real way to know exactly what is and is not protected. It shouldn’t be your only line of defense, it’s more of a safety net so nothing slips through to an “unsafe operation.” On the other hand, it has nothing to do with application security, and won’t save your data or users from being compromised. And on top of that, MRI has a history of vulnerabilities that bypass $SAFE entirely.

    • 0