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.