CERT
Skip to end of metadata
Go to start of metadata

Information for Editors
To have a new guideline automatically listed above be sure to label it msc and rule.

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MSC30-CMediumUnlikelyLow

P6

L2

MSC32-CMediumLikelyLow

P18

L1

MSC33-CHighLikelyLow

P27

L1

MSC37-CHighUnlikelyLow

P9

L2

MSC38-CLowUnlikelyMedium

P2

L3

MSC39-CLowUnlikelyLow

P3

L3

MSC40-CLowUnlikelyMedium

P2

L3

 


7 Comments

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

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

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

    1. 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?

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

  3. 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).

    1. 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:

      • rigorous
      • easily defensible
      • universally agreed-upon

      The first two are easy, but I suspect you'll have a hard time getting everyone to agree where to draw the line.