Page History

Redundant testing by caller and by callee as a style of defensive programming is largely discredited in the C and C++ communities, the main problem being performance. The usual discipline in C and C++ is to require validation on only one side of each interface.

Requiring the caller to validate arguments can result in faster code because the caller may understand certain invariants that prevent invalid values from being passed. Requiring the callee to validate arguments allows the validation code to be encapsulated in one location, reducing the size of the code and making it more likely that these checks are performed in a consistent and correct fashion.

For safety and security reasons, this standard recommends that the called function validate its parameters. Validity checks allow the function to survive at least some forms of improper usage, enabling an application using the function to likewise survive. Validity checks can also simplify the task of determining the condition that caused the invalid parameter.

Noncompliant Code Example

In this noncompliant code example, setfile() and usefile() do not validate their parameters. It is possible that an invalid file pointer can be used by the library, corrupting the library's internal state and exposing a vulnerability.

/* Sets

When writing a library, perform a validity check on parameters passed to functions exposed as part of the public API. This allows the developer using the library to catch errors early, and it could protect the internal state of the library from corruption.

Non-Compliant Coding Example

For these examples, a library exposes an API as follows.

/* sets some internal state in the library */
extern int setfile(FILE *file);

/* performsPerforms some action using the file passed earlier */
extern int usefile();

In this non-compliant example, setfile and usefile do not validate their parameters. It is possible that an invalid file pointer may be used by the library, possibly corrupting the library's internal state and exposing a vulnerability.

static FILE *myFile;

intvoid setfile(FILE *file) {
    myFile = file;
    return 0;
}

intvoid usefile(void) {
    /* performPerform some action here */
    return 0;
}

The vulnerability is can be more severe if the internal state references sensitive or system-critical data.

Compliant Solution

Validating the function parameters and verifying the internal state leads to consistency of program execution and may eliminate potential vulnerabilities. In addition, implementing commit or rollback semantics (leaving program state unchanged on error) is a desirable practice for error safety.

/* Sets some internal state in the library */
extern errno_t setfile(FILE *file);

/* Performs some action using the file passed earlier */
extern errno_t usefile(void);

static FILE *myFile;

interrno_t setfile(FILE *file) {
    if (file && !ferror(file) && !feof(file)) {
        myFile = file;
        return 0;
    }

  /* Error safety: leave myFile =unchanged NULL;*/
    return -1;
}

interrno_t usefile(void) {
    if (!myFile)
        return -1;

    /* perform
     * Perform other checks if needed,; return 
     * error condition.
     */

    /* performPerform some action here */
    return 0;
}

Risk Assessment

The most likely result of ignoring this recommendation is Failing to validate the parameters in library functions may result in an access violation or a data integrity violation. Such a scenario is indicative of scenario indicates a flaw in the manner in which how the library is used by the calling code. However, it the library itself may still be the library itself that is the vector by which the calling code's vulnerability is exploited.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Key here (explains table format and definitions)

Bibliography

...

Image Added Image Added Image Added