You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

Variadic functions can accept a variable number of arguments, but are problematic. Variadic functions define an implicit contract between the function writer and the function user that allows the function to determine the number of arguments passed passed in any particular invocation. Failure to exercise care when invoking a variadic function to ensure that it knows when to stop processing arguments, or incorrect management of the argument list, may result in stack corruption.

Argument Processing

In the following code example, the variadic function average() is used to determine the average value of its passed integer arguments [[Seacord 05c]]. The function processes arguments until it finds one with a value of -1.

int average(int first, ...) {
  size_t 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(count ? (sum / count) : 0);
}

Note that va_start() must be called to initialize the argument list and va_end() must 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 from a vulnerabilityin 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 CVE-2006-1174 . If the stack is manipulated by an attacker, the missing argument, which controls access permissions, can 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:

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

Argument List Caveats

C99 functions that accept the variadic primitive va_list as an argument pose an additional risk. Calls to vfprintf(), vfscanf(), vprintf(), vscanf(), vsnprintf(), vsprintf(), and vsscanf() use the va_arg() macro, invalidating the parameterized va_list. Consequently, once a va_list is passed as an argument to any of these functions, it cannot be used again except in a call to the va_end() macro.

Risk Assessment

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

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

DCL10-A

2 (medium)

2 (probable)

2 (medium)

P8

L2

Related Vulnerabilities

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

References

[[ISO/IEC 9899-1999]] Section 7.15, "Variable arguments"; 7.19.6.8 "The vfprintf function"
[[Seacord 05c]]

  • No labels