This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

FORTIFY_SOURCE provides lightweight compile and runtime protection to some memory and string functions (original patch to gcc was submitted by Red Hat). It is supposed to have no or a very small runtime overhead and can be enabled for all applications and libraries in an operating system. The concept is basically universal meaning it can be applied to any operating system, but there are glibc specific patches available in gcc-4 onwards. In gcc, FORTIFY_SOURCE normally works by replacing some string and memory functions with their *_chk counterparts (builtins). These functions do the necessary calculations to determine an overflow. If an overflow is found, the program is aborted; otherwise control is passed to the corresponding string or memory operation functions. Again all this is normally done in assembly so the overhead is really minimal.

While there are some technical articles which talk about FORTIFY_SOURCE in detail, this article discusses broad objectives of this technology and how it can help developers prevent some vulnerabilities related to buffer overflows.

How does FORTIFY_SOURCE actually work

As mentioned earlier, depending on the code, gcc can detect buffer overflows during compile time and runtime.

Consider a buffer of fixed size which is declared as:

char buf[5];

Here are possible scenarios FORTIFY_SOURCE can effectively work with:

  1. Fixed data being copied into buf
memcpy (buf, foo, 5);
strcpy (buf, "abcd");

In this case size of the data being copied into buf is known (5 bytes in first case and 4 chars plus a null byte in the second case), therefore FORTIFY_SOURCE can easily determine at compile time that no buffer overflow is possible, so memcpy/strcpy can be called directly or even inlined.

  1. Again, fixed data being copied into buf
memcpy (buf, foo, 6);
strcpy (buf, "abcde");

Again size of the data is known, but seems to be incorrect. The compiler can detect buffer overflows at compile time. It issues warnings at compile time, and calls the checking alternatives at runtime.

  1. Variable data being copied into buf
memcpy (buf, foo, n);
strcpy (buf, bar);

The compiler knows the number of bytes remaining in object, but doesn't know the length of the actual copy that will happen at runtime. FORTIFY_SOURCE replaces memcpy or strcpy with wrapper functions __memcpy_chk or __strcpy_chk which checks if a buffer overflow happened. If buffer overflow is detected, __chk_fail () is called (the normal action is to abort () the application, perhaps by writing some message to stderr).

  1. Variable data copied into buffer whose size is not known:
memcpy (p, q, n);
strcpy (p, q);

This is not check-able at compile time or at runtime. FORTIFY_SOURCE cannot be used to protect against overflows if they occur.

Functions protected by FORTIFY_SOURCE

Memcpy, memset, stpcpy, strcpy, strncpy, strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf, gets(3), and wide character variants thereof. For some functions, argument consistency is checked; for example, a check is made that open(2) has been supplied with a mode argument when the specified flags include O_CREAT.

How to enable FORTIFY_SOURCE

During compile D_FORTIFY_SOURCE macro needs to be set in order to enable FORTIFY_SOURCE. There are two levels of checking which are implemented. Setting the macro to 1 will enable some checks (the man page says that "checks that shouldn't change the behavior of conforming programs are performed"), while setting it to 2 adds some more checking.

The difference between -D_FORTIFY_SOURCE=1 and -D_FORTIFY_SOURCE=2
is e.g. for:

struct S { 
    struct T {
         char buf[5];
          int x; 
          } t;
     char buf[20]; 
} var;

With -D_FORTIFY_SOURCE=1, "strcpy (&var.t.buf[1], "abcdefg");" is not considered an overflow (object is whole VAR), while with -D_FORTIFY_SOURCE=2 "strcpy (&var.t.buf[1], "abcdefg");" will be considered a buffer overflow.

Another difference is that with -D_FORTIFY_SOURCE=2, "%n" in format strings of the most common *printf family functions is allowed only if the format string is stored in read-only memory (usually string literals, gettext's _("%s string %n") is fine too). Usually, when an attacker attempts to exploit a format string vulnerability, the "%n" is injected by the attacker, so it is necessarily a writable memory.

In conclusion FORTIFY_SOURCE is lightweight and quite effective at controlling some categories of overflows, but again like any other security technology it is not perfect and should be enabled in combination with others.

About the author

Huzaifa Sidhpurwala is a principal Product Security Engineer, working for Red Hat Product Security Team.

Read full bio