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

Compare with Current View Page History

« Previous Version 29 Next »

When writing a library, each exposed function should perform a validity check on its parameters. Validity checks allow the library to survive at least some forms of improper usage, enabling an application using the library to likewise survive, and often simplifies the task of determining the condition that caused the invalid parameter.

Non-Compliant Coding Example

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, corrupting the library's internal state and exposing a vulnerability.

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

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

static FILE *myFile;

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

int usefile() {
    /* perform some action here */
    return 0;
}

The vulnerability may 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.

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

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

static FILE *myFile;

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

  myFile = NULL;
  return -1;
}

int usefile() {
  if (!myFile) return -1;

    /* perform other checks if needed, return error condition */

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

Risk Assessment

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 a flaw in the manner in which the library is used by the calling code. However, it may still be the library itself that is the vector by which the calling code's vulnerability is exploited.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

MSC08-A

2 (medium)

1 (unlikely)

1 (high)

P2

L3

Automated Detection

The LDRA tool suite V 7.6.0 is able to detect violations of this recommendation.

Related Vulnerabilities

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

References

Apple, Inc. Secure Coding Guide: Application Interfaces That Enhance Security. Retrieved Apr 26, 2007.


MSC07-A. Detect and remove dead code      13. Miscellaneous (MSC)       MSC09-A. Character Encoding - Use Subset of ASCII for Safety

  • No labels