SP 500-268 - 02/03/2007-01

[SAMATE Home | IntrO TO SAMATE | SARD | SATE | Bugs Framework | Publications | Tool Survey | Resources]

Sender: pmeunier <pmeunier [at] cerias.net (pmeunier[at]cerias[dot]net)>

Subject: About the NIST Draft 500-268

Re: teaching CWE, CCE, CVE Reading the NIST draft -- there are some "interesting" (which I believe incorrect) associations being made in Appendix A, and possibly incorrect or misleading uses of the CWE.

-Why are all the issues with taintedness not under "Input validation"? Especially 251, which is put under API abuse.

-The text of the CWE entry for 251 is significantly different from the text in the NIST document. Actually they appear to me as completely different issues. There is no mention of trusted malicious string lengths in the 251 CWE. The NIST document needs to quote an additional CWE number, creating it if necessary. I think that the CWE 251 text is clear in its meaning and shouldn't be changed.

-Stack and Heap overflows don't require tainted data to happen. The CWE definition doesn't mention taintedness either. Why is the NIST document introducing taintedness in the definition? Is it to specifically limit the scope? Then it a new CWE ID should be defined for it. Using the same CWE ID as the general case implies that the scanners have capabilities they don't and is misleading.

-Format string vulnerabilities is a range error? I realize that from a language and stack manipulation point of view, arguments may be read that are not there, but that's not the only way a format string vulnerability can exist. I can contrive a format string issue without attempting to read missing elements. I'm also confused because it departs from the CWE, which lists it as a child of injection. I also think of it as an input validation and injection issue, regardless of the machine mechanics. If you classify things from the perspective of errors that programmers make, format string issues should be grouped with input validation issues.

-Not cleaning reused memory is a general problem -- there doesn't need to be an API being abused for it to be an issue (c.f. the Sun tar vulnerability). Is this again an attempt to narrow the scope of the issue? http://cwe.mitre.org/data/definitions/244.html doesn't mention anything about APIs. It also doesn't mention anything about free(). Either the text of the CWE entry needs to be changed, or an extra one needs to be mentioned in the NIST document (and created in the CWE if necessary).

-Are the state-of-the art checkers incapable of detecting any integer overflow issues?

-I have a number of issues with the resource injection #99 entry in the CWE, which I emailed separately to Steve.

Regards, Pascal My credentials and association for the benefit of the NIST folks being cc'ed on this:

Pascal Meunier, Ph.D., M.Sc., CISSP Purdue University CERIAS

To Comments on SP 500-268, Jan 2007