Page History

Null-terminated byte strings (NTBS) must be properly null-terminated before they can be safely passed 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:

size_t i;
char ntbs[16];
/* ... */
for (i = 0; i < sizeof(ntbs); ++i) {
  if (ntbs[i] == '\0') break;
  /* ... */
}

Failure to properly terminate null-terminated byte strings can are, by definition, null-terminated. String operations cannot determine the length or end of strings that are not properly null-terminated, which can consequently result in buffer overflows and other undefined behavior.

...

Exceptions

...

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.

Related Vulnerabilities

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

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.

Rejected 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.

References

\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.1.1, "Definitions of terms," and Section 7.21, "String handling <string.h>"
\[[Seacord 05|AA. C References#Seacord 05]\] Chapter 2, "Strings"
\[[ISO/IEC TR 24731-2006|AA. C References#ISO/IEC TR 24731-2006]\] Section 6.7.1.4, "The strncpy_s function"
\[[Viega 05|AA. C References#Viega 05]\] Section 5.2.14, "Miscalculated null termination"