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 ([Seacord]). Variadic functions can also be unsafe because the macros used to process the argument list circumvent the C type system. If care is not exercised when invoking a variadic function to ensure that it knows when to stop processing arguments or that the argument it is processing is the right fundamental type, there may be dangerous consequences.
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); }
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);
The C99 function printf()
is also implemented as a variadic function, if care is not taken to ensure that the conversion specifiers to printf()
match up with the type of the intended parameter, the result may be abnormal program termination.
The following code swaps its null terminated byte string and integer parameters with respect to how they were specified in the format string. This means that the integer will be silently casted into a pointer to a null terminated byte string and then dereferenced, possibly causing the program to abnormally terminate (error_message pointer will likewise be silently converted into an integer).
char const *error_msg = "Error occurred"; /* ... */ printf("%s:%d", 15, error_message);
As shown, care should be taken that the arguments passed to a format string function match up with the supplied format string.
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.
char const *error_msg = "Error occurred"; /* ... */ printf("Error (%s): %s", error_msg);
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 |
References
[[ISO/IEC 9899-1999:TC2]] Section 7.15, "Variable arguments"