, , , , , , , ,

Having recently been introduced to the Rough Auditing Tool for Security (RATS) in a discussion on alternative methods of analysing software on a UNIX-based system, I’ve decided to do a quick practical and write-up on it.

I often make the point that understanding the background of a given programming language, and the libraries being used, is often more important than knowing the syntax. This is especially important to know when using RATS as it scans only the source file, and vulnerabilities could exist outside that source in whatever external objects it calls. What this means from an attackers’ perspective is that a native OS function/object with a vulnerability could be indirectly exploited through a range of user-space programs. Moral of the story here: It’s important to know precisely what a vulnerability scanner is looking at.

How does RATS work? The idea is there are a limited (but fairly large) number of places where vulnerabilities could exist in a source file, and these tend to exist at certain points – for example, passing values to a function, reading/scanning input, format conversions. RATS has a database of known coding flaws for PHP, Python, C, Ruby and Perl, and it looks for matches within a given source file.

The databases are XML files that can be found in /usr/share/rats. In the case of C source, it’s actually vuln_db.c that goes looking for potential matches.

A Test Program
Let’s test this on a simple program that does the following:
printf("%s\n", getpwuid(getuid()) -> pw_gecos);

Of course, it contains function printf() that in turn contains functions getpwuid() and getuid().


As we can see, just running it on sesh.c gives us pretty simplistic output. It did a lookup on database files for Perl, Ruby, C, Python and PHP and scanned through the 14 lines of code without flagging anything. Maybe we should scan a larger source file that’s known to cause a buffer overflow.

An Example Using Known Buffer Overflow Code
I still have the C program from a 3rd year BSc module (which I might have covered here before) that attempts to cause a buffer overflow condition, using strcpy() to copy from one 8-byte buffer into another. Anything over that should cause an overflow or at the very least an exception.


We can test this quickly by compiling the program with gcc and running it. The Gnu Debugger will give the same output plus the physical address and function where the exception occurred.


RATS is useful because it should detect this within the source code before it’s compiled and executed. In real-world software development, RATS can provide a routine method of eliminating obvious vulnerabilities before the software’s initial release.


Another useful feature is the ability to produce HTML markup for the output, which could be copied and pasted into an HTML file, displayed in a browser and maybe printed for inclusion in a technical report.

$rats BufferOverflowEx1.c --html