Null-terminated byte strings (NTBS) must be properly null-terminated before they can be safely passed as arguments to standard string handling functions such as strcpy()
or strlen()
that depend on the null-termination character to determine to find the end of the string. Similarly, NTBS must be null-terminated before iterating on a character array where the termination condition of the loop depends on the existence of a null-termination character within the memory allocated for the string, as in the following example:
...
Include Page | ||||
---|---|---|---|---|
|
Mitigation Strategies
Static Analysis
Violations of this rule can be detected using local flow analysis assuming an integer range analysis to track the length of the strings. (Note: I am not entirely familiar with the literature on buffer-overflow analysis, but we should check that none of them already handle this scenario.)
...
This analysis also impacts STR03-A, STR07-A, and STR31-C.
Alternative Strategies
Testing
It would probably be prohibitively expensive to come up with the test cases by hand. Another option is to use a static analysis to generate the test inputs for char*. However, it would still have to generate the inputs for the other values. We would still have to specify whether the function allows open strings or can return open strings, so that the dynamic analysis knows whether to report a defect. Since we still have to write the specifications, this technique will not save developer time there.
Dynamic Analysis
It seems the analysis won't be very different from the static analysis, in which case, we should just do this statically.
Inspection
An inspection would essentially grep for known problem functions and inspect the usage. Obviously, this is extremely costly, as there would be a lot of false positives, and this does not scale well. There may also be many false negatives. Say Dev A inspects a function that returns an open string. Dev A considers it ok and documents it as such, perhaps this is one of the exception cases. Dev B might be inspecting another part of the code and might not realize that Dev A allowed an open string. It might be documented, but this is not very reliable. This might lead to a false sense of confidence that since the developers hand inspected every case that the code is fine, when in fact, a miscommunication can cause a defect.
Risk Assessment
Failure to properly null terminate null-terminated byte strings can result in buffer overflows and the execution of arbitrary code with the permissions of the vulnerable process by an attacker.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
STR32-C | 3 (high) | 2 (probable) | 2 (medium) | P12 | L1 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Wiki Markup |
---|
\[[ISO/IEC 9899-1999:TC2|AA. C References#ISO/IEC 9899-1999TC2]\] Section 7.1.1, "Definitions of terms," and Section 7.21, "String handling <string.h>" \[[ISO/IEC TR 24731-2006|AA. C References#ISO/IEC TR 24731-2006]\] Section 6.7.1.4, "The strncpy_s function" \[[Schwarz 05|AA. C References#Schwarz 05]\] \[[Seacord 05|AA. C References#Seacord 05]\] Chapter 2, "Strings" \[[Viega 05|AA. C References#Viega 05]\] Section 5.2.14, "Miscalculated null termination" |