Rats

---

The Rough Auditing Tool for Security (RATS), from Secure Software Inc., tries to help programmers smooth the rough edges of their C, C++, Perl, PHP, Python, or OpenSSL applications. Unlike Flawfinder, RATS is written in C and contains external XML collections of rules that apply to each language. RATS also took the “easy way out” by using a Lexer to tokenize source files before they are parsed by the main RATS engine.

Implementation

RATS compiles easily on most Unix systems, although you need to make sure that you have the Expat XML Parser installed (http://sourceforge.net/projects/expat/). This is less of a problem on Linux systems because the major distributions have started including the library. Once Expat is installed, compilation is a ./configure and make away.

RATS 2.1 expands the tool’s support and use of XML data, which makes it easier to write custom checks. Its usage remains relatively the same, but now a native Windows binary is available in addition to the original Unix version. Many of the command-line flags have synonyms—for example –d is equivalent to –db or --database. See the following table for more information about the available options.

usage: rats [-adhilrwxR] [--help] [--database|--db] name1 name2 ... namen

RATS Option	Description
-a <fun>	Report any occurrence of function “fun" in the source file(s)
-d <filename>	Specify an alternative vulnerability database
-h	Display usage information
-i	Report functions that accept external input
-l <language>	Force the specified language to be used
-r	Include references that are not function calls
-w <1,2,3>	Set warning level (the default is 2)
-x	Do not load default databases
-R	Do not recurse subdirectories scanning for matching files
--xml	Output in XML
--html	Output in HTML
--follow-symlinks	Follow symlinks and process files found
--noheader	Do not print initial header in output
--nofooter	Do not show timing information footer at end of analysis
--quiet	Do not print status information regarding what file is being analyzed
--resultsonly	No header, footer, or status information
--columns	Show column number of the line where the problem occurred
--context	Display the line of code that caused the problem report
name1 name2 ... namen	File names of source code to audit, accepts wildcards

RATS assumes the file(s) are written in C, but it will switch its assumption based on limited filename extensions:

• Perl .pl, .pm

• PHP .php

• Python .py, .PY

Use the –l option to force C, Perl, Python, or PHP. The C and C++ checks use the same list of functions and syntax errors. The Perl, Python, and PHP language checks do not really examine idiosyncrasies of the particular language. The Perl checks, for example, focus on underlying system functions (meaning "C-equivalent" functions) as opposed to stringent checks on Perl syntax and variable management. You can still have a highly insecure web application built in Perl (or Python or PHP); RATS performs only basic checks. In RATS’s defense, Perl’s data types do not easily lend themselves to strong type checking and boundary tests, nor are Perl scripts vulnerable to buffer overflows in the same sense as a C program.

One of the interesting additions to RATS is the rats-openssl.xml file that contains a list of common functions from the OpenSSL library and cautions for properly using, allocating, and referencing buffers. These are part of the C-language checks and would help anyone developing C or C++ web applications.

Note 

Perl provides a –T option to "taint" variables. Perl never passes tainted variables to a system function (such as exec). This accomplishes the majority of the input validation tests for shell metacharacters normally required in a secure program, but it is far from adequate—especially in web applications.

The –a and –d options come in handy for extending RATS. Use –a to instruct RATS to make grep-like searches for a particular function. The –d option is even more useful, but you will have to be comfortable with XML syntax. For example, here’s one of RATS’s check structures on the tmpfile function:

<!ENTITY tmpfile "Many calls for generating temporary file names are insecure (susceptible to race conditions). Use a securely generated file name, for example, by pulling 64 bits of randomness from /dev/random, base 64 encoding it and using that as a file suffix.">

Within the six new Windows-specific checks is the equivalent temporary file caution:

<!ENTITY w32tmppath "GetTempPath() may return the current directory or the windows directory. Be careful what you place in these locations. Important files may be overwritten, and trojan DLL's may be dropped in these locations. Never use a user-input filename when writing to a location given by GetTempPath().">

Other checks cover Windows-specific functions such as pathbuf, dllload, and w32exec. Note that just looking for the existence of a function probably causes more false positives than necessary, but it serves to highlight potential problem areas.

Case Study: mtr 0.46

MTR is a General Public License (GPL) tool that combines the functionality of traceroute and Ping. Damian Gryski identified a buffer overflow condition in the way MTR handles the MTR_OPTIONS environment variable (Bugtraq ID 4217). Environment variables have a long history as attack vectors for buffer overflows. Thus, it’s no surprise that RATS checks for functions that use environment variables.

$ rats mtr.c mtr.c:72: High: getopt_long Truncate all input strings to a reasonable length before passing them to this function mtr.c:139: High: fixed size local buffer Extra care should be taken to ensure that character arrays that are allocated on the stack are used safely. They are prime targets for buffer overflow attacks. mtr.c:180: High: getenv Environment variables are highly untrustable input. They may be of any length, and contain any data. Do not make any assumptions regarding content or length. If at all possible avoid using them, and if it is necessary, sanitize them and truncate them to a reasonable length. mtr.c:185: High: printf mtr.c:190: High: printf Check to be sure that the non-constant format string passed as argument 1 to this function call does not come from an untrusted source that could have added formatting characters that the code is not prepared to handle. mtr.c:236: High: gethostbyname DNS results can easily be forged by an attacker (or arbitrarily set to large values, etc.), and should not be trusted.

Here’s the line of code that generated the finding in RATS (the same line could have been found with a grep getenv mtr.c command):

parse_mtr_options (getenv ("MTR_OPTIONS"));

RATS identified a potential vulnerability. It is up to the auditor to trace the vulnerability into the parse_mtr_options function and determine whether or not the finding is valid. Przemyslaw Frasunek crafted an exploit that illustrated how the parse_mtr_options function mishandled the MTR_OPTIONS variable. Here’s the section of the vulnerable code:

while (p) {     argv[argc++] = p;     p = strtok (NULL, " \t");  }

The p variable is a pointer to the memory location that could contain not only the value of the MTR_OPTIONS environment variable, but also the data that could be placed into memory and used to execute arbitrary commands. The strtok C function operates on strings stored in memory, looking for patterns specified in its second argument (" \t" or a space and tab character combination in this example). When strtok receives a NULL value for its first argument, it operates on the current pointer, in this case p. However, an attacker could craft a malicious MTR_OPTIONS that causes the pointer to be overwritten with shellcode—in other words, execute an arbitrary command.

The author’s patch implements a length check on the p variable and reports extraneous data:

while (p && (argc < (sizeof(argv)/sizeof(argv[0])))) {     argv[argc++] = p;     p = strtok (NULL, " \t");  }  if (p) {      fprintf (stderr, "Warning: extra arguments ignored: %s", p);  }

An audit from RATS and a follow-through on the recommendation, “Do not make any assumptions regarding content or length,” would have negated the attack.

Case Study: Canaries in the Mist

In the opening paragraph of this chapter, we wished for a compiler that would create the “unbreakable” application. Stackguard, from http://immunix.org, is a collection of patches to the GCC compiler. These patches turn GCC into a proactive “securifier” of any C or C++ code that it compiles.

The basic concept is that function calls potentially vulnerable to buffer overflows have “canaries” (random values) appended to their memory space. When an attacker attempts a buffer overflow, the attack corrupts the memory space that contains the canary. The program recognizes that the canary has been modified and abruptly halts—without executing any malicious code inserted by the attacker.

We would only echo the excellent Stackguard documentation to describe the buffer overflow protection in adequate detail. Check out the http://immunix.org web site for more information.

The OpenBSD and Linux kernel developers have both started projects that will attempt to stop the most common buffer overflows. To give an unfairly simple description of their techniques, the OpenBSD group is separating the read, write, and execute permissions on the memory pages made available to a program. So if a buffer overflow vulnerability were present, but the memory was read-only or nonexecutable, the exploit would fail. The Linux gr-security patch provides similar mechanisms for blocking stack execution as well as strict access control lists for programs.

Keep in mind that Stackguard and “nonexecutable stack” settings are not a panacea for buffer overflows. There are documented techniques for circumventing many Stackguard-like protections. Secure your network, your host, and then the application—redundancy always helps.

If you’re more interested in secure coding, you may be interested in a few of these links:

• NET Secure Coding Guidelines, at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconsecurecodingguidelines.asp

• Reviewing Code for Integer Manipulation Vulnerabilities, at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/ secure04102003.asp

• Secure Programming HOWTO, at http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html

---