Redundant testing by caller and by callee as a style of defensive programming is largely discredited within discredited in the C and C++ communitycommunities, the main problem being performance. The usual discipline in C and C++ is to require validation on only on one side of each interface.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
/* setsSets some internal state in the library */ extern int setfile(FILE *file); /* performsPerforms some action using the file passed earlier */ extern int usefile(); static FILE *myFile; void setfile(const FILE *file) { myFile = file; } void usefile(void) { /* performPerform some action here */ } |
The vulnerability can be more severe if the internal state references sensitive or system-critical data.
...
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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
/* setsSets some internal state in the library */ extern interrno_t setfile(FILE *file); /* performsPerforms some action using the file passed earlier */ extern interrno_t usefile(void); static FILE *myFile; errno_t setfile(FILE *file) { if (file && !ferror(file) && !feof(file)) { myFile = file; return 0; } /* errorError safety: leave myFile unchanedunchanged */ return EINVAL-1; } errno_t usefile(void) { if (!myFile) return -1; /* * performPerform other checks if needed,; return * error condition. */ /* performPerform some action here */ return 0; } |
...
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.
Recommendation | Severity | Likelihood | Detectable |
|---|
Repairable | Priority | Level |
|---|---|---|
API00-C | Medium |
Unlikely |
|---|
No |
No | P2 | L3 |
|---|
Automated Detection
Tool | Version | Checker | Description |
|---|
| Section |
|---|
| Astrée |
| Supported | |||||||
| CodeSonar |
| LANG.STRUCT.UPD | Unchecked parameter dereference | ||||||
| Parasoft C/C++test |
| CERT_C-API00-a | The validity of parameters must be checked inside each function | ||||||
| PC-lint Plus |
| 413, 613, 668 | Partially supported: reports use of null pointers including function parameters which are assumed to have the potential to be null | ||||||
| PVS-Studio |
| V781, V1111 |
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)
...
Taxonomy | Taxonomy item | Relationship |
|---|---|---|
| CERT C |
...
...
| Prior to 2018-01-12: CERT: Unspecified Relationship | ||
| CWE 2.11 | CWE-20, Insufficient input validation | Prior to 2018-01-12: CERT: |
| MITRE CWE | CWE-476 | Prior to 2018-01-12: |
Bibliography
...
MITRE CWE: CWE ID 20, "Insufficient Input Validation"
Bibliography
| Wiki Markup |
|---|
\[[Apple 2006|AA. Bibliography#Apple 06]\] [Application Interfaces That Enhance Security|http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html], May 2006. |
13. Application Programming Interfaces (API) 13. Application Programming Interfaces (API)