FLAWFINDER

---

Flawfinder, written by Dave Wheeler, collected the most common C and C++ programming errors and dropped them into a tool that would check source for their presence. The tool does not understand C syntax or subtle programming techniques; however, it serves well as a quick sanity check of your applications. It is written in readable Python and has just over 1000 lines, which makes it an excellent candidate for customization.

Implementation

Flawfinder’s power comes from its catalog of problematic functions. It provides several options, but you will most likely need to use only a few of them. A complete list is provided in Table 11-1.

Table 11-1: Flawfinder Command-Line Options

Option	Description
--allowlink	Follow symbolic links.
--context -c	Display the line that contains the potential flaw; similar to using grep to search for each function and showing the results of each match.
--columns	Display the column number of the potential flaw. For example, a vulnerable strcpy might start at the sixteenth character on the line.
--dataonly	Do not display the headers and footers for findings.
--listrules	View the current database of checks. This will list about 120 C/C++ functions with known problems and their relative risk (on a scale of 1 to 5, 5 is high).
--minlevel=X -m X	Set the minimum risk level for which a hit is reported. The value of X can equal 0 (no risk) through 5 (highest risk). The default is 1.
--neverignore -n	Do not honor the ignore directive in a source file.
--html	Provide report as HTML.
--immediate -i	Display potential flaws as they are found.
--inputs	Display only functions that receive external input (set variables from data obtained outside of the program). Sets minlevel to 0.
--quiet	Do not display hit information during a scan.
--loadhitlist=F	Load hits from file F instead of analyzing source programs.
--savehitlist=F	Save hits to file F.
--diffhitlist=F	Do not display hits contained in file F. Useful for comparing revisions.

The quickest way to run Flawfinder is to specify a directory or list of files to check:

$ flawfinder src/

By default, Flawfinder examines only the C files it encounters. It determines a C file based on the filename extension: c, h, ec, ecp, pgc, C, cpp, cxx, cc, pcc, hpp, or H. Even though it doesn’t fully understand C, Flawfinder does partially distinguish between potential vulnerable functions that use variables as opposed to constants, evaluating the former as a higher risk.

If one of your files does not have one of the default extensions, you can specify it on the command line, like so:

$ flawfinder ftpcmd.y

The output is formatted as such:

filename:line_number:column_number [risk_level] (type) function_name:message 

The column_number is omitted unless the --columns option is present. Use the –m option to catch risk levels of a certain number or higher. Flawfinder places each hit into a category (type): buffer overflow, race condition, inadequate random number source, and mishandled temporary file.

Use the --savehitlist option to save the output to a file. This makes it easier for you to review output, especially for large projects. The --difflist option also helps when handling large projects. Flawfinder ignores hits already present in the filename specified after the option (--difflist < filename>). Thus, you can save hit files at various stages of development to keep track of new functions.

In the course of auditing your code, Flawfinder may sometimes hit a false positive. If you want to have Flawfinder ignore a line, place one of the following three directives before the line to ignore:

/* Flawfinder: ignore */ /* RATS: ignore */ /* ITS4: ignore */

You can also insert these lines with C++ style comments (//). When Flawfinder sees one of these ignore directives in source code, it does not report errors on the succeeding line—regardless of how insecure the line may be.

As you can see, Flawfinder plays well with other audit tools’ directives.

Case Study: wu-ftpd 2.6.0

The Washington University FTP server suffered growing pains during its evolution from version 2.4 through 2.6. One of the vulnerabilities brought to Bugtraq’s attention by [e-mail] (Bugtraq ID 1387) belonged to a class of vulnerabilities based on format strings. Flawfinder contains a catalog of misused functions and reports every one it finds:

$ flawfinder ftpd.c flawfinder version 0.21, (C) 2001 David A. Wheeler. Number of dangerous functions in C ruleset: 55 Examining ftpd.c?ftpd.c:5593 [5] (race) chown: this accepts filename arguments; if an attacker can move those files, a race condition results. . Use fchown( ) instead. ftpd.c:412 [4] (format) vsnprintf: if format strings can be influenced by an attacker, they can be exploited. Use a constant for the format specification. ftpd.c:416 [4] (format) snprintf: if format strings can be influenced by an attacker, they can be exploited. Use a constant for the format specification. ftpd.c:684 [4] (buffer) strcpy: does not check for buffer overflows. Consider using strncpy or strlcpy. ftpd.c:3158 [4] (buffer) sprintf: does not check for buffer overflows. Use snprintf or vsnprintf. ftpd.c:5890 [4] (buffer) sprintf: does not check for buffer overflows. Use snprintf or vsnprintf. ftpd.c:6160 [4] (format) syslog: if syslog's format strings can be influenced by an attacker, they can be exploited. Use a constant format string for syslog. ftpd.c:6618 [4] (format) vsnprintf: if format strings can be influenced by an attacker, they can be exploited. Use a constant for the format specification.

The four lines in boldface type correspond to these lines in the source code:

sprintf(proctitle, "%s: %s", remotehost, pw->pw_name); ... sprintf(proctitle, "%s: connected", remotehost);

The actual exploit affected the lines immediately following the sprintf functions, but this shows how Flawfinder may point you in the right direction for tracking down programming errors. For example, part of the patch released to fix the format string error looks like this (a - at the beginning of a line means to delete the line; a + means to add it):

remotehost[sizeof(remotehost) - 1] = '\0'; sprintf(proctitle, "%s: connected", remotehost); -setproctitle(proctitle); +setproctitle("%s", proctitle);

Case Study: What Automated Audit Tools Miss

Automated tools understand the syntax rules of a programming language. They detect problems inherent to a specific function or how that function is commonly misused. Automated tools cannot find or solve logic-based problems in source code. Logic-based problems involve arithmetic, Boolean comparisons, and variable substitution.

Integer Mismatches   In C and C++ applications, programmers store numeric variables in a variety of formats: 16-bit, 32-bit, signed (may have negative values), or unsigned (positive values only). OpenSSH was vulnerable to a CRC-32 compensation attack, discovered by Michal Zalewski (Bugtraq ID 2347), that exploited a problem with the storage of two mismatched numeric variables. The vulnerability required only a one-line fix to change a variable n from a 16-bit value to a 32-bit value:

- static word16 n = HASH_MINSIZE / HASH_ENTRYSIZE; + static word32 n = HASH_MINSIZE / HASH_ENTRYSIZE;

This value was used later in a FOR loop that operated on a 32-bit value, l:

u_int32_t l; for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2); if (h == NULL) {    debug("Installing crc compensation attack detector.");    n = l;    h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE); }

The value for n was initially 4096. The FOR loop would multiply l by 2 (l=l<<2) until it passed a certain limit. It was possible for l to reach a value of 65536; however, the maximum value for a 16-bit number is only 65535. Consequently, n would be set to zero. This did not affect the Secure Shell (SSH) until another FOR loop used the value for a later function:

register u_int32_t i; for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;

If n equals zero, then n–1 equals –1, but to an unsigned 32-bit integer –1 looks like 0xFFFFFFFF in hexadecimal notation (it cannot be negative). In other words, HASH(c) & (n-1) becomes HASH(c), a value that an attacker can manipulate.

Boolean Tests    Logical tests and implied boundary values also lead to errors—but errors that cannot be found automatically. For example, the OpenSSH Channel Code Off-By-One vulnerability (Bugtraq ID 4241) discovered by Joost Pol is due to a subtle error in checking a numeric boundary. Take a look at the vulnerable code (the first line) and the fix (the second line):

- if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) {

The whole IF statement looks like this:

if (id 0 || id >= channels_alloc) {            log("channel_lookup: %d: bad id", id);            return NULL;       }       c = channels[id];

The vulnerable IF statement does not execute if the id value equals the channels_alloc limit. This causes problems in the next command, when the program tries to call the channels[id] array.

Precompiled Binaries    A source-code auditing tool cannot audit a binary executable. Truisms aside, this drives home the fact that good security must rely on up-to-date patch levels, host configurations that follow least-privilege design, and strong network controls. For example, consider the .ida buffer overflow in Microsoft IIS:

• Patch level    It was a zero-day exploit, so users had to wait for Microsoft to release a patch. Of course, the vulnerability is still being exploited six months later, pointing to other problems with configuration management or lack of user education.

• Host security    If users had removed unused ISAPI filters—.ida in particular—the vulnerability would not have been accessible. If the application had been shipped in a least-privilege state (for example, users add ISAPI filters as they need them), users would not have had this problem in the first place. How many users needed the .printer extension (which also had a buffer overflow)?

• Network security    Affected many organizations’ servers that belonged to test networks, internal networks that erroneously permitted incoming web traffic, or servers deployed without acknowledgement of the security group.

Even if you have access to source code, you may still be unable to identify security holes. You can, however, apply methods from each of the three preceding concepts to block or at least mitigate security vulnerabilities in the software on your network.

Auditing compiled programs for buffer overflows is not impossible, but it requires a greater understanding of memory and processor architectures. No serious commercial tools or open source projects are publicly available that automatically search for common problems within a binary. Usually, the only tools necessary are a pad of paper, a few pencils, and a debugger. The tools are simple, but the techniques are more difficult and beyond the scope of this book.

---