Risk Assessment Summary
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
| MSC30-C | Medium | Unlikely | Low | P6 | L2 |
| MSC32-C | Medium | Likely | Low | P18 | L1 |
| MSC33-C | High | Likely | Low | P27 | L1 |
| MSC37-C | High | Unlikely | Low | P9 | L2 |
| MSC38-C | Low | Unlikely | Medium | P2 | L3 |
| MSC39-C | Low | Unlikely | Low | P3 | L3 |
| MSC40-C | Low | Unlikely | Medium | P2 | L3 |
| MSC41-C | High | Probable | Medium | P12 | L1 |
8 Comments
Stephen Friedl
This feels like the right section to encourage use of compiler helpers such as GNU _attribute_() to add helpers or diagnostics to the code. For instance, writing your own variadic function die(const char *format, ...) can be tagged to have GCC check the params just like it would for the "native" printf.
Ref: http://www.unixwiz.net/techtips/gnu-c-attributes.html
David Keaton
We tend to advocate standard solutions here, as discussed in Scope.
Although we occasionally mention implementation-specific details, this particular one would be problematic because the C committee is debating whether to add some sort of attribute specification to the language, and if so, in what form. If this document advocated the GCC-specific method and then the C committee chose a different one, the conflict could cause difficulties for people.
Greg Beeley
Would it be possible to have an entire section of the C secure coding standard dedicated to rules and recommendations for API design? A lot of problems in C were created due to poorly designed API's and/or API's with missing functionality.
Robert Seacord
Sure, anything is possible. Generally speaking we would create a new section for an area if we had a significantly sized cluster of rules in one area.
What other rules/recommendations would you like to see?
Greg Beeley
Here are a few, I'm sure we could think of more...
I believe that rule MSC08-A here would fit (which is what actually brought the subject to mind), although I would include such things as:
"When designing a new function which copies or generates data, the function should take a parameter to specify the size constraints of the destination"
"When designing a new function which copies or generates data, the function should provide a clear indication when truncation has occurred due to inadequate space in the destination"
I believe the rule MEM00-A would also fit, from the perspective of designing the API so that memory is allocated and free'd at the same level of abstraction.
Also, rule MEM01-A may imply designing API's which automatically set pointers to NULL on a free() operation, by taking a pointer to the pointer for the free() function's parameter.
Eric Decker
Many standards for safety and security critical standards also strongly recommend that the McCabe cyclomatic complexity of functions by limited to less than or equal to 10 (I believe both the DO-178B and NIST SP 500-235 standards recommend this value). Limiting functions to this makes the code easier to evaluate and test (although not easier to code).
David Svoboda
While simpler, smaller functions are universally recognized as easier to build & maintain, they are not always possible. Many functions, especially for parsers and compilers, will contain long switch statements that really cannot easily be broken up into smaller functions. There is a good example of such a function in the Linux kernel that is described in this rule: MEM12-C. Consider using a Goto-Chain when leaving a function on error when using and releasing resources. Furthermore, reducing function complexity addresses good software engineering, not security (although it is indirectly addressed, as vuls tend to hide better in complex code.)
I think for a rule addressing complexity to survive on this wiki it has to be:
The first two are easy, but I suspect you'll have a hard time getting everyone to agree where to draw the line.
Volker Erben
Only for completeness: Please add MSC41-C also in table "Risk Assessment Summary"