oreilly.comSafari Books Online.Conferences.


Secure Programming Techniques
Pages: 1, 2

Coding Standards

  1. Check all of your input arguments. An astonishing number of security-related bugs arise because an attacker sends an unexpected argument or an argument with an unanticipated format to a program or a function within a program. A simple way to avoid these kinds of problems is by having your program always check all of its arguments. Argument checking will not noticeably slow down most programs, but it will make them less susceptible to hostile users. As an added benefit, argument checking and error reporting will make the process of catching non-security-related bugs easier.

  2. When you are checking arguments in your program, pay extra attention to the following:

  3. • Check arguments passed to your program on the command line. Check to make sure that each command-line argument is properly formed and bounded.

    • Check arguments that you pass to Unix system functions. Even though your program is calling the system function, you should check the arguments to be sure that they are what you expect them to be. For example, if you think that your program is opening a file in the current directory, you might want to use the index( ) function to see if the filename contains a slash character (/). If the filename contains the slash, and it shouldn't, the program should not open the file.

    •Check arguments passed to your program via environment variables, including general environment variables (e.g., HOME) and such variables as the LESS argument.

    • Do bounds checking on every variable. If you only define an option as valid from 1 to 5, be sure that no one tries to set it to 0, 6, -1, 32767, or 32768. If string arguments are supposed to be 16 bytes or less, check the length before you copy them into a local buffer (and don't forget the room required for the terminating null byte). If you are supposed to have three arguments, be sure you have three.

  4. Check all return codes from system calls. Practically every single Unix operating system call has a return code. Check them! Even system calls that you think cannot fail, such as write( ), chdir( ), and chown( ), can fail under exceptional circumstances and return appropriate return codes. When the calls fail, check the errno variable to determine why they failed. Have your program log the unexpected value and then cleanly terminate if the system call fails for any unexpected reason. This approach will be a great help in tracking down problems later on.

    If you think that a system call should not fail and it does, do something appropriate. If you can't think of anything appropriate to do, then have your program delete all of its temporary files and exit.

  5. Have internal consistency-checking code. Use the assert macro if you are programming in C. If you have a variable that you know should be either a 1 or a 2, then your program should not be running if the variable is anything else.

    Editor's note: Be aware that the assert() macro is nullified when you compile with the NDEBUG flag enabled. This is a common release optimization. Please read man assert for more details.

  6. Include lots of logging. You are almost always better off having too much logging rather than too little. Report your log information into a dedicated log file. Or consider using the syslog facility so that logs can be redirected to users or files, piped to programs, and/or sent to other machines. And remember to do bounds checking on arguments passed to syslog( ) to avoid buffer overflows.

    Here is specific information that you might wish to log:

    • The time that the program was run.
    • The UID and effective UID of the process.
    • The GID and effective GID of the process.
    • The terminal from which it was run.
    • The process number (PID). If you log with syslog, including the LOG_PID option in the openlog( ) call will do this automatically.
    • Command-line arguments.
    • Invalid arguments, or failures in consistency checking.
    • The host from which the request came (in the case of network servers).
    • The result of an ident lookup on that remote host.

  7. Always use full pathnames for any filename argument, for both commands and data files.

  8. Check anything supplied by the user for shell metacharacters if the user-supplied input is passed on to another program, written into a file, or used as a filename. In general, checking for good characters is safer than checking for a set of "bad characters" and is not that restrictive in most situations.

  9. If you are expecting to create a new file with the open call, then use the O_EXCL | O_CREAT flags to cause the routine to fail if the file exists. If you expect the file to be there, be sure to omit the O_CREAT flag so that the routine will fail if the file is not there.[12]

  10. If you think that a file should be a file, use lstat( ) to make sure that it is not a link. However, remember that what you check may change before you can get around to opening it if it is in a public directory.

  11. If you need to create a temporary file, consider using the tmpfile( ) or mkstemp( ) functions. tmpfile( ) creates a temporary file, opens the file, deletes the file, and returns a file handle. The open file can be passed to a subprocess created with fork( ) and exec( ), but the contents of the file cannot be read by any other program on the system. The space associated with the file will automatically be returned to the operating system when your program exits. If possible, create the temporary file in a closed directory, such as /tmp/root/. mkstemp( ) does not delete the file and provides its name as well as its file handle, and thus is suitable for files that need more persistence.

    WARNING: Older versions of mkstemp( ) could create world-writable files. Make sure yours doesn't. Never use the mktemp( ) or tmpnam( ) library calls if they exist on your system--they are not safe in programs running with extra privilege. The code as provided on most older versions of Unix had a race condition between a file test and a file open. This condition is a well-known problem and is relatively easy to exploit.

  12. Make good use of available tools. If you are using C and have an ANSI C compiler available, use it, and use prototypes for calls. If you don't have an ANSI C compiler, then be sure to use the -Wall option to your C compiler (if supported) or the lint program to check for common mistakes. Use bounds checkers, memory testers, and any other commercial tools to which you have access.

Things to Avoid

  1. Don't use routines that fail to check buffer boundaries when manipulating strings of arbitrary length.

    In the C programming language in particular, note the following:


    Use instead

    gets( )

    fget( )

    strcpy( )

    strncpy( )

    strcat( )

    strncat( )

    sprintf( )

    snprintf( )

    vsprintf( )

    vsnprintf( )

  2. Use the following library calls with great care--they can overflow either a destination buffer or an internal, static buffer on some systems if the input is "cooked" to do so: [13] fscanf( ) scanf( ), sscanf( ), realpath( ), getopt( ), getpass( ), streadd( ), strecpy( ), and strtrns( ). Check to make sure that you have the version of the syslog( ) library that checks the length of its arguments.

    There may be other routines in libraries on your system of which you should be somewhat cautious. Note carefully if a copy or transformation is performed into a string argument without benefit of a length parameter to delimit it. Also note if the documentation for a function says that the routine returns a pointer to a result in static storage (e.g., strtok( )). If an attacker can provide the necessary input to overflow these buffers, you may have a major problem.

  3. Don't design your program to depend on Unix environment variables. The simplest way to write a secure program is to make absolutely no assumptions about your environment and to set everything explicitly (e.g., signals, umask, current directory, environment variables). A common way of attacking programs is to make changes in the runtime environment that the programmer did not anticipate.

    Thus, you should make certain that your program environment is in a known state. Here are some of the things you may want to do:

    • If you absolutely must pass information to the program in its environment, then have your program test for the necessary environment variables and then erase the environment completely.

    • Otherwise, wipe the environment clean of all but the most essential variables. On most systems, this is the TZ variable that specifies the local time zone, and possibly some variables to indicate locale. Cleaning the environment avoids any possible interactions between it and the Unix system libraries.

    •You might also consider constructing a new envp and passing it to exec( ), rather than using even a scrubbed original envp. Doing so is safer because you explicitly create the environment rather than try to clean it.

    • Make sure that the file descriptors that you expect to be open are open, and that the file descriptors you expect to be closed are closed. Consider what you'll do if stdin, stdout, or stderr is closed when your program starts (a safe option is usually to connect them to /dev/null.) For example, components of Wietse Venema's Postfix mailer often include this C snippet:

    for (fd = 0; fd < 3; fd++)
       if(fstat(fd, &st) == -1 && (close(fd), open("/dev/null", O_RDWR, 0)) != fd)
          msg_fatal("open /dev/null: %m");

    • Ensure that your signals are set to a sensible state.

    • Set your umask appropriately.

    • Explicitly chdir ( ) to an appropriate directory when the program starts.

  4. Do not provide shell escapes in interactive programs (they are not needed).

  5. Never use system( ) or popen( ) calls. Both invoke the shell, and can have unexpected results when they are passed arguments with funny characters, or in cases where environment variables have peculiar definitions.

  6. Do not create files in world-writable directories.

  7. Don't have your program dump core except during your testing. Core files can fill up a filesystem and contain confidential information. In some cases, an attacker can actually use the fact that a program dumps core to break into a system. Instead of dumping core, have your program log the appropriate problem and exit. Use the setrlimit( ) function or equivalent to limit the size of the core file to 0. While you're at it, consider setting limits on the number of files and stack size to appropriate values if they might not be appropriate at the start of the program.

Before You Finish

  1. Read through your code. After you have written your program, think of how you might attack it yourself. What happens if the program gets unexpected input? What happens if you are able to delay the program between two system calls?

  2. Test it carefully for assumptions about the operating environments. For example:

    • If you assume that the program is always run by somebody who is not root, what happens if the program is run by root? (Many programs designed to be run as daemon or bin can cause security problems when run as root, for instance.)

    • If you assume that the program will be run by root, what happens if it is not run as root?

    • If you assume that the program always runs in the /tmp or /tmp/root [14] directory, what happens if it is run somewhere else? What if /tmp/root is a symlink? What if it doesn't exist?

  3. Test your program thoroughly. If you have a system based on SVR4, consider using (at the least) tcov, a statement-coverage tester (and if your system uses GNU tools, try gcov). Consider using commercial products, such as Centerline's CodeCenter and Rational's PurifyPlus (from personal experience, we can tell you that these programs are very useful). Remember that finding a bug in testing is better than letting some anonymous attacker find it for you!

  4. Have your code reviewed by another competent programmer (or two, or more). After she has reviewed it, "walk through" the code with her and explain what each part does. We have found that such reviews are a surefire way to discover logic errors. Trying to explain why something is done a certain way often results in an exclamation of "Wait a moment . . . why did I do that?"

    TIP: Simply making your code available for download is not the same as having a focused review! The majority of code published on the Web and via FTP is not carefully examined by competent reviewers with training in security and code review. In most cases, the people who download your code are more interested in using it, or porting it to run on their toaster than they are in providing meaningful code review. Keep this in mind about code you download, too--especially if someone claims that the code must be correct because it has had thousands of downloads.

  5. If you need to use a shell as part of your program, don't use the C shell. Many versions have known flaws that can be exploited, and nearly every version performs an implicit eval $TERM on startup, enabling all sorts of attacks.

    We recommend the use of ksh (used for some of the shell scripts in this book). It is well-designed, fast, powerful, and well-documented (see Appendix C). Alternatively, you could write your scripts in Perl, which has good security for many system-related tasks.

Remember: many security bugs are actually programming bugs, which is good news for programmers. When you make your program more secure, you simultaneously make it more reliable.

Be sure to check back to this space next week for tips on writing network programs.


[9] "It's not a bug, it's a feature!"

[10] For some reason, people writing new software for Unix (and especially Linux) have forgotten this basic principle of Unix.

[11] Donald Knuth said: "Premature optimization is the root of all evil." Although "all evil" may be a bit extreme, it does seem to be at the root of a great number of programming errors.

[12] Note that on some systems, if the pathname in the open( ) call refers to a symbolic link that names a file that does not exist, the call may not behave as you expect. This scenario should be tested on your system so you know what to expect.

[13] Not all of these are available under every version of Unix.

[14] We use /tmp/root with the understanding that you have a directory /tmp/root automatically created by your startup scripts, and that this directory has a mode of 0700. Your /tmp directory should have mode 1777, which prevents ordinary users from deleting the /tmp/root directory.

Return to

Sponsored by: