Null-terminated byte strings 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.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Exception
An exception to this rule applies if the intent of the programmer is to convert a null-terminated byte string to a character array. To be compliant with this standard, this intent must be clearly stated in comments.
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.
Mitigation Strategies
(Section under construction by Ciera. Just wanted to get some current notes down here before I clean it up.)
Static Analysis
A local analysis should work fine here. We will assume that all byte string parameters to a method are required to be null terminated and are guaranteed to be null terminated after the function.
In the case where it is not required or not guaranteed, we will have to create a separate specification. Given that this is C, the best option might be two hardcoded handling routines in the analysis. If the function either accepts an open string (not null terminated) or can return an open string, we can write some code to specify this. The analysis calls these handling routines to retrieve these specifications.
Another option would be to utilize the preprocessor. However, I don't think that is in the style of C programmers. Additionally, we can't add these specs to libraries that way. Given the environment, a separate specification, in C, is probably the best option.
We also need to assume that there is a string length analysis.
Once we have this information, we can do a local flow analysis. The lattice has 4 elements, bottom, NT(null terminating), O(open) and top(unknown). If we index into the string and set a character to '\0', move the string to NT. The hard part here is knowing the size of the string. We need to make sure the index is not past the existing size of the string, measured either as strlen() on an NT char* or sizeof().
Check that we do not pass in O or M strings to methods that require NT. Also check that we meet our own out specifications.
There is a question of what to do about character arrays. One option is to assume that char[] is open, and using it as a char* means that we first must make it null terminating. This could get annoying for developers very quickly. I think it's better to treat char[] as char*, that is, we assume NT and check for it. If the exception case does occur, it will have to be specified.
This analysis also impacts STR03-A, STR07-A, and STR31-C.
Combined attack (SA/DA/T)
Static analysis to generate test cases, dynamic analysis instruments the code that the test cases run on. Will have slightly different tradeoffs to SA. Good if we don't know the codebase well enough to create the handlers for non-NT functions. More work up front to create this kind of analysis, but reusable to many codebases. Provides the breadth of static analysis, the preciseness of dynamic analysis, and the repeatability of testing. Will have to think through this algorithm more carefully.
Rejected Strategies
Testing
It would probably be prohibitively expensive to come up with the test cases by hand.
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]] Section 7.1.1, "Definitions of terms," and Section 7.21, "String handling <string.h>"
[[Seacord 05]] Chapter 2, "Strings"
[[ISO/IEC TR 24731-2006]] Section 6.7.1.4, "The strncpy_s function"
[[Viega 05]] Section 5.2.14, "Miscalculated null termination"