Using lint to Find Insecure Code

Description

 Lint is a tool that has traditionally been used to warn about C coding practices that may lead to errors. A full build of the ON consolidation runs lint on the entire kernel plus a fraction of the commands and libraries. Although lint does not currently run on all ON code, new code is generally required to be lint-clean and existing code is occasionally modified to fix lint warnings. As a result, the portion of the ON source base covered by lint increases over time.
 Sun Studio lint has a new option that warns about potentially unsafe use of library routines that may result in buffer overflows or other security vulnerabilities. The new lint security checks are enabled by specifying the -errsecurity option with one of three levels: core, standard, or extended. Each level includes everything in the previous level plus additional checks. Click here for a description of what is included at each level. Currently the lowest level,  core, is enabled for all source files that are linted. This level may be rasied to standard sometime in the future.

Running lint in ON source directories

 The top-level ON makefiles include -errsecurity=core in the default set of lint options, so a simple make lint in any source directory will include this option. To run the security checks at one of the other levels, simply override the SECLEVEL variable on the command line; e.g., make lint SECLEVEL=standard.

Fixing common lint warnings

 Like other warnings from lint, the security warnings do not necessarily indicate that the code in question is incorrect or unsafe. Instead, they mean that the code is not obviously safe so that lint can determine this from a static analysis of the source code. A person may be able to examine the code and determine that it is safe, but modifying the code to avoid the warning saves every future maintainer of the code from having to repeat that analysis.
 The three most common security warnings found in ON code are:

1. variable format specifier to printf()

Format strings used with the printf family of functions should be fixed string literals. If they are variables derived from user input, overflow attacks using the %n format specifier are possible. Some techniques for fixing code like this:

• Instead of printf(str) use printf("%s", str) or puts(str).
• For functions that are wrappers around printf for debugging, error messages, etc., be sure the function is marked with the /*PRINTFLIKE*/ lint directive. This allows lint to verify that the arguments to the function match the format string, and it suppresses the warning when the variable format string is passed to vprintf.
• Note that lint treats the strings returned from gettext and dgettext as constants, so it's OK to use them in place of string literals.
• If you must use a variable format string (e.g. to select at runtime between two fixed format strings), declare the variable as a const char * to suppress the lint warning.

2. format argument to sprintf() contains an unbounded string specifier

A format string that contains %s can write an unlimited amount of output, possibly overflowing the fixed-size buffer passed to sprintf. Two simple techniques to fix this are:

• Use snprintf instead of sprintf. The size argument places an upper bound on the number of characters that will be written to the buffer.
• Change the format string to limit the number of characters written, e.g. %10s to write at most 10 characters. This is also the reason lint does not complain about sprintf calls that use fixed-size formats like %d.

3. format argument to scanf() contains an unbounded string specifier

Just as it does in the case above, a %s in a scanf format string can write an unlimited number of characters and possibly overflow the buffer supplied. For scanf, however, only one fix is available:

• Change the format string to limit the number of characters. Important: The size given in the format string does not include the trailing null character, so a format of %10s requres an 11-byte buffer.

 Finally, note that the /*LINTED*/ directive and -erroff command-line option can be used to suppress any of the security warnings just as they can for any other lint warning.

Availability

 The lint security-checking feature is included in Sun Studio 9 and later releases.