Variadic functions provide the ability to specify accept a variable number of arguments to a function, but they can be but are problematic. Variadic functions contain define 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 consequencesallows the function to determine the number of arguments passed in any particular invocation. Failure to enforce this contract may result in undefined behavior. See undefined behavior 141 of Appendix J of the C Standard.
Argument Processing
In the following code example, a the variadic function called average()
(taken from an article written by Robert Seacord for Linux World Magazine on variadic functions) is used to determine calculates the average value of its passed the positive integer arguments passed to the function [Seacord 2013]. The function will stop processing processes arguments when it sees that the argument is -1
until it encounters an argument with the value of va_eol
(-1
).
Code Block |
---|
enum { va_eol = -1 }; unsigned int average(int first, ...) { unsigned int count = 0; unsigned int sum = 0; int i = first; va_list markerargs; va_start(markerargs, first); while (i != -1va_eol) { sum += i; count++; i = va_arg(markerargs, int); } va_end(markerargs); return(sumcount ? (sum / count) : 0); } |
Note that va_start()
must always be called to initialize the argument list and that va_end()
must be called when finished with a variable argument list.
Noncompliant Code Example
In this noncompliant code example, the average()
However, if the function is called as follows:
Code Block | ||||
---|---|---|---|---|
| ||||
int avg = average(1, 4, 6, 4, 1);
|
The omission of the -1
va_eol
terminating value means that on some architectures, the function will continue to grab process values from the stack until it either hits a -1
encounters a va_eol
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.
...
bgColor | #ffcccc |
---|
...
or an error occurs.
Compliant Solution
This compliant solution enforces the contract by adding va_eol
as the final argument:
Code Block | ||||
---|---|---|---|---|
| ||||
int avg = average(1, 4, 6, 4, 1, va_eol);
|
Noncompliant Code Example
...
Another common mistake is to use more format conversion specifiers than supplied arguments, as shown in this noncompliant code example:
Code Block | ||||
---|---|---|---|---|
| ||||
const char *error_msg = "Resource not available to user."; /* ... */ printf("Error (%s): %s", error_msg); |
This code results in nonexistent arguments being processed by the function, potentially leaking information about the process.
Compliant Solution
This compliant solution matches the number of format specifiers with the number of variable 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:
Code Block | ||||
---|---|---|---|---|
| ||||
const char const *error_msg = "Resource not available to user."; /* ... */ printf("Error (%s): %s", error_msg); |
Argument List Caveats
C99 C functions that themselves that take accept the variadic primitive va_list
as an argument pose an additional thread when dealing with variadic functionsrisk. Calls to vfprintf()
, vfscanf()
, vprintf()
, vscanf()
, vsnprintf()
, vsprintf()
, and vsscanf()
use the va_arg()
macro, invalidating the parameterized va_list
. ThusConsequently, this once a va_list
must not be used except for is passed as an argument to any of these functions, it cannot be used again without a call to the va_end()
macro once any of those functions are used followed by a call to va_start()
.
Risk Assessment
Incorrectly using a variadic function can result in abnormal program termination or unintended information disclosure.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
DCL10- |
2 (medium)
2 (probable)
2 (medium)
P8
L2
References
C | High | Probable | High | P6 | L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| Supported, but no explicit checker | |||||||
Helix QAC |
| C0185, C0184 | |||||||
Klocwork |
| SV.FMT_STR.PRINT_PARAMS_WRONGNUM.FEW SV.FMT_STR.PRINT_PARAMS_WRONGNUM.MANY SV.FMT_STR.SCAN_PARAMS_WRONGNUM.FEW SV.FMT_STR.SCAN_PARAMS_WRONGNUM.MANY | |||||||
LDRA tool suite |
| 41 S | Enhanced Enforcement | ||||||
Parasoft C/C++test |
| CERT_C-DCL10-a | The number of format specifiers in the format string and the number of corresponding arguments in the invocation of a string formatting function should be equal | ||||||
PC-lint Plus |
| 558, 719 | Assistance provided: reports issues involving format strings | ||||||
Polyspace Bug Finder |
| Checks for format string specifiers and arguments mismatch (rec. partially covered) |
Related Guidelines
ISO/IEC TR 24772:2013 | Subprogram Signature Mismatch [OTR] |
MISRA C:2012 | Rule 17.1 (required) |
MITRE CWE | CWE-628, Function call with incorrectly specified arguments |
Bibliography
[Seacord 2013] | Chapter 6, "Formatted Output" |
...
\[[ISO/IEC 9899-1999:TC2|AA. C References#ISO/IEC 9899-1999TC2]\] Section 7.15, "Variable arguments"; 7.19.6.8 "The {{vfprintf}} function" Wiki Markup