DCL10-A. Take care when using variadic functions

Variadic functions provide the ability to specify a variable number of arguments to a function, but they can be problematic. Variadic functions contain an implicit contract between the function writer and the function user that must be made to establish how many arguments are passed on an invocation. If care is not exercised when invoking a variadic function to ensure that it knows when to stop processing arguments and that the argument list is used incorrectly, there may be dangerous consequences. It should be noted that variadic functions must always have an ellipsis as a parameter, or the result is undefined.

Argument Processing

In the following code example, a variadic function called average() (taken from an article written by Robert Seacord for Linux World Magazine on variadic functions) is used to determine the average value of its passed integer arguments. The function will stop processing arguments when it sees that the argument is -1.

int average(int first, ...) {
  int count = 0;
  int sum = 0;
  int i = first;
  va_list marker;

  va_start(marker, first);

  while (i != -1) {
    sum += i;
    count++;
    i = va_arg(marker, int);
  }

  va_end(marker);
  return(sum ? (sum / count) : 0);
}

Note that va_start() must always be called to initialize the argument list and va_end() should always be called when finished with a variable argument list.

However, if the function is called as follows:

  int avg = average(1, 4, 6, 4, 1);

The omission of the -1 terminating value means that on some architectures, the function will continue to grab values from the stack until it either hits a -1 by coincidence, or until it is terminated.

In the following line of code, which is an actual vulnerability in an implementation of a useradd function from the shadow-utils package, the POSIX function open() (which is implemented as a variadic function) is called missing an argument. If the stack is maliciously manipulated, the missing argument, which controls access permissions, could be set to a value that allows for an unauthorized user to read or modify data.

fd = open(ms, O_CREAT|O_EXCL|O_WRONLY|O_TRUNC);

Another common mistake is to use more format specifiers than supplied arguments. This results in undefined behavior, which could end up pulling extra values off the stack and unintentionally exposing data. The following example illustrates a case of this:

char const *error_msg = "Resource not available to user.";
/* ... */
printf("Error (%s): %s", error_msg);

Argument List Caveats

C99 functions that themselves that take the variadic primitive va_list pose an additional thread when dealing with variadic functions. Calls to vfprintf(), vfscanf(), vprintf(), vscanf(), vsnprintf(), vsprintf(), and vsscanf() use the va_arg() macro, invalidating the parameterized va_list. Thus, this va_list must not be used except for a call to the va_end() macro once any of those functions are used.

Risk Assessment

Incorrectly using a variadic function can result in abnormal program termination or unintended information disclosure.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[ISO/IEC 9899-1999:TC2]] Section 7.15, "Variable arguments"; 7.19.6.8 "The vfprintf function"