Some Security Concerns While Programming In Ruby

by Satish Talim on April 28, 2008

Making critical information available across the Internet has arguably been one of the most profound business enablers in the history of technology. It has meant expanded markets, increased productivity, and streamlined processes. Unfortunately, it has also meant a profound increase in operational risk. Vulnerabilities like command injection attacks result from inadequately designed or written Ruby code, creating opportunities for attackers to threaten privacy and steal data. The only way to eliminate vulnerabilities is to get them where they live: in the source code itself.

Let me show you two possible vulnerabilities:

  1. System Commands and Command Injection Attacks: The Ruby language supports the use of system commands. Generally, these calls are used to execute external functions outside of the program, including launching a different application or URL, sending an email, gaining access to files, or executing other commands from the operating system. The module Kernel provides the system method. From a security perspective, Kernel.system provides an opportunity for a user to bypass normal security measures by injecting malicious input into the application. If the parameter to the system command is not validated, an attacker can execute any command on the system for which the application has privileges. For example, if an attacker can terminate the intended command string using “;” or “&”, they may be able to insert their own malicious commands such as “rm –rf /” or “del /S /Q ?AS *”. In general, there are no safe way to use system. If system must be called, then extreme care should be taken to ensure that input is properly validated prior to being used to execute a system command.
  2. Improper Exception Handling: Improper error messages can provide critical information about an application which may aid an attacker in exploiting the application. The most common problem occurs when detailed internal error messages such as stack traces, database dumps, and error codes are displayed to the user. Security analysts view logging and error handling as potential areas of risk. It is recommended that production applications should not use, for example, a puts e.backtrace.inspect call unless it is being directly committed into a log that is not viewable to the end user.

By analyzing the code itself to identify these flaws and errors, organizations can drastically reduce their levels of risk and exposure.

What other vulnerabilities in Ruby (not Rails) can you think of? I’d definitely like to hear and add them here.

Hat Tip: The idea for this post came while reading Ounce Labs’ solutions that enable organizations to identify, prioritize and eliminate business risk to the enterprise, caused by software security vulnerabilities.

Technorati Tags: ,

Posted by Satish Talim

{ 5 comments… read them below or add one }

jan. April 28, 2008 at 4:13 pm

Why is this specific to ruby? The title of the post seems to imply that these 2 issues are ruby-related. But don’t we see them appear in a wide range of languages?

The author is correct that these are security concerns that should be kept under control, but they apply to _whatever_ language you use.


Startrader April 28, 2008 at 9:32 pm

As an extension of the Kernel.system exploit, the #exec method is also vulnerable to attack and for the same reasons. The killer here is that there are an huge number of ways to execute arbitrary ruby code in the library code of many popular packages. Long and the short of it: if a string came from an untrusted user, treat it like a live bomb and know exactly what your program (including library calls) is going to do with it.


Greg June 10, 2008 at 6:24 pm

From what I can tell there are four vectors for command-injection in Ruby. They all require the same treatment (generally avoidance when untrusted input is involved) but you should be wary of:

` (The back-tick operator)


Henryk Gerlach August 12, 2008 at 7:30 pm

> In general, there are no safe way to use system.
I don’t know, how you came to this conclusion.

There are 2 ways to call system (

a) with a single string
system(“echo $(seq 5)”)
that’s prone to shell injection, unless the string is properly escaped (see e.g.

b) with a command-string and each argument as an additional string:
system(“echo”, “$(seq 5)”)

This is save against shell injection. (as save as the called command/shell script).


Henryk Gerlach August 18, 2008 at 12:23 am

What other vulnerabilities in Ruby (not Rails) can you think of? I’d definitely like to hear and add them here.
Well, constantize is more dangerous, than it looks like see

This is nothing new (cf. but I show how to exploit it in conjunction another security hole.


Leave a Comment

{ 2 trackbacks }

Previous post:

Next post: