Macros are frequently used in the remediation of existing code to globally replace one identifier with another, for example, when an existing API changes. Although some risk is always involved, this practice becomes particularly dangerous if a function name is replaced with the function name of a deprecated or obsolescent function. Deprecated functions are defined by the C Standard and Technical Corrigenda. Obsolescent functions are defined by MSC24-C. Do not use deprecated or obsolescent functions.
Although compliance with rule MSC24-C. Do not use deprecated or obsolescent functions guarantees compliance with this recommendation, the emphasis of this recommendation is the extremely risky and deceptive practice of replacing functions with less secure alternatives.
Noncompliant Code Example
The Internet Systems Consortium's (ISC) Dynamic Host Configuration Protocol (DHCP) contained a vulnerability that introduced several potential buffer overflow conditions [VU#654390]. ISC DHCP makes use of the
vsnprintf() function for writing various log file strings;
vsnprintf() is defined in the Portable Operating System Interface (POSIX®), Base Specifications, Issue 7 [IEEE Std 1003.1:2013] as well as in the C Standard. For systems that do not support
vsnprintf(), a C include file was created that defines the
vsnprintf() function to
vsprintf(), as shown in this noncompliant code example:
#define vsnprintf(buf, size, fmt, list) \ vsprintf(buf, fmt, list)
vsprintf() function does not check bounds. Consequently,
size is discarded, creating the potential for a buffer overflow when untrusted data is used.
The solution is to include an implementation of the missing function
vsnprintf() to eliminate the dependency on external library functions when they are not available. This compliant solution assumes that
__USE_ISOC11 is not defined on systems that fail to provide a
#include <stdio.h> #ifndef __USE_ISOC11 /* Reimplements vsnprintf() */ #include "my_stdio.h" #endif
Replacing secure functions with less secure functions is a very risky practice because developers can be easily fooled into trusting the function to perform a security check that is absent. This may be a concern, for example, as developers attempt to adopt more secure functions, such as the C11 Annex K functions, that might not be available on all platforms. (See STR07-C. Use the bounds-checking interfaces for string manipulation.)
|Supported, but no explicit checker|
|Axivion Bauhaus Suite|
|Polyspace Bug Finder|
Rec. fully covered.
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
|SEI CERT C++ Coding Standard||VOID PRE09-CPP. Do not replace secure functions with less secure functions|
|ISO/IEC TR 24772:2013||Executing or Loading Untrusted Code [XYS]|
|MITRE CWE||CWE-684, Failure to provide specified functionality|
|[IEEE Std 1003.1:2013]||XSH, System Interfaces, vsnprintf, |
|[Seacord 2013]||Chapter 6, "Formatted Output"|
This rule is was tagged 'rose-possible', because, given an ontology of secure functions and less-secure functions, one could identify macros that replaced secure functions with their less-secure counterparts. Other than the bad & good examples, we have no such ontology, and would need to create one before checking this with ROSE.
Currently marked 'unenforceable'.
There is a good chance I'll move the table over to a new guideline, MSC34-C.
Lucas Clemente Vella
The wording of this rule is inconsistent with MSC24-C. In here,
vsnprintf()is shown as safe and allowed. In MSC24-C, it is marked as "Unchecked Obsolescent Function".
The vsnprintf() function is obsolesced by the vsnprintf_s() function from Annex K in C11 (and newer editions). However, Annex K is conditionally normative...if your platform supports Annex K and general and vsnprintf_s() in particular, use it instead. But if your platform does not support Annex K, you must still use vsnprintf().