Page History

...

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

Assume all in parameters require NT, all out params provide NT.
Write specialized handlers for any function where this is not the case (should not be too many. Default should be that strings are NT as soon as possible.)
O represents open strings, M represents maybe case (top of lattice).
Local analysis. Make sure we meet our own handler requirements, too.
Few false positives, as those that accept NT are specified. Probably will still get some FP from pointer magic.
Consider affects on 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|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"