Security Policy

Reporting a Vulnerability

To report a security vulnerability, please email the mruby team at matz@ruby.or.jp. We appreciate your efforts to disclose your findings responsibly.

Scope

mruby is an embeddable Ruby implementation. Its security model is designed for integration into a host application, which is responsible for sandboxing and resource management. This policy defines what we consider a security vulnerability within the mruby interpreter itself.

High Priority Security Vulnerabilities

We consider the following issues to be high priority security vulnerabilities:

• Remote Code Execution (RCE): The ability to execute arbitrary machine code or shell commands from within a Ruby script, beyond the intended execution scope of the script itself.

Lower Priority: Crashes (Preferably Report as Bugs)

We accept but deprioritize the following issues. We recommend reporting them as bug reports on our issue tracker rather than security reports:

• VM Crash on Valid Ruby Code: Segmentation faults, assertion failures, or other interpreter crashes triggered by syntactically and semantically valid Ruby scripts.
  • Recommendation: Please report these as bugs on our issue tracker.
  • Rationale: While we will fix these issues, they typically only result in denial of service (DoS), not arbitrary code execution. They are lower priority than RCE vulnerabilities.
  • Note: This does not include standard Ruby exceptions like TypeError or ZeroDivisionError, which are expected behavior.
  • Example: A segmentation fault when running [1, 2, 3].map { |x| x * 2 } is best reported as a bug.

Out of Scope: Not Considered Security Vulnerabilities

We do not consider the following issues to be security vulnerabilities:

• Resource Exhaustion: Infinite loops, excessive memory allocation, or high CPU usage originating from a Ruby script.

  • Rationale: The host application is responsible for implementing resource limits, sandboxing, and execution timeouts. mruby provides the execution engine; the host provides the constraints.
  • Example: loop {} or "a" * (2**30) are not vulnerabilities, even if they lead to memory or CPU exhaustion.

• Crashes from Malformed Bytecode: Crashes resulting from loading or executing corrupted or intentionally malformed .mrb files.

  • Rationale: mruby's bytecode format is not a security boundary. Applications should only execute bytecode from trusted sources.
  • Example: A crash discovered by fuzzing .mrb files is not considered a vulnerability.

• Crashes from C API Misuse: Crashes caused by incorrect usage of mruby's C API from the embedding application.

  • Rationale: The C API is a trusted interface for developers. The caller is responsible for adhering to the API contract (e.g., not passing NULL pointers, managing object lifetimes correctly).
  • Example: Calling mrb_funcall() with an invalid mrb_state* pointer is not a vulnerability.

• Theoretical Undefined Behavior (UB): Issues reported by tools like ASAN, UBSan, or Valgrind that do not lead to a demonstrable crash or exploitable behavior in practice.

  • Rationale: While we strive for clean, well-defined code, our focus is on practical security impact. We prioritize fixing UB that is exploitable over issues that are purely theoretical.
  • Example: An integer overflow in an intermediate calculation that gets handled correctly before affecting program output or control flow.

• Warnings on Large Memory Allocations: Tooling warnings related to large memory allocations that do not result in a crash.

  • Rationale: mruby is designed to handle malloc(3) returning NULL on large allocation requests. This is considered graceful error handling, not a vulnerability.

Summary

• High Priority Security Reports: Remote code execution vulnerabilities.
• Accepted (but preferably as bug reports): VM crashes from valid Ruby code.
• Not Accepted as Security Issues: Resource exhaustion, malformed bytecode, C API misuse, theoretical undefined behavior, or allocation warnings.