NIST Response to SP 500-268 - 02/03/2007-01

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

NIST: OUR RESPONSES TO COMMENT SP 500-268 - 02/03/2007-01 ON THE DRAFT Source Code Security Analysis TOOL SPECIFICATION ARE INTERSPERSED WITH THE MESSAGE.

Sender: pmeunier <pmeunier [at] cerias.net (pmeunier[at]cerias[dot]net)>
Subject: About the NIST Draft 500-268
e: 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.

NIST: WE ARE USING THE WEAKNESS CATEGORIES PROVIDED BY CWE. WE AGREE THAT CWE 251 (STRING MANAGEMENT) IS A TAINTEDNESS ISSUE AS WELL AS AN API-ABUSE ISSUE. ACTUALLY, MANY OF THE WEAKNESSES IN OUR LIST COULD LIKELY FALL UNDER MULTIPLE CATEGORIES. RATHER THAN TRYING TO “PIGEONHOLE” A WEAKNESS THAT MAY IN FACT FALL UNDER MULTIPLE CWE CATEGORIES, WE ARE CHOOSING TO USE THE CWE "PARENT" NODE FOUND IN THE CWE TAXONOMY TREE TO BEST ALIGN OUR EFFORT WITH THEIRS. IF THIS WEAKNESS SHOULD REALLY BE LISTED UNDER "INPUT VALIDATION" THEN THIS IS SOMETHING THAT SHOULD BE DISCUSSED WITH THE CWE FOLKS.

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

NIST: AS OF 5 APRIL 2007 THE DESCRIPTION FOR CWE 251 IS

OUR DESCRIPTION IS

WE ARGUE THAT THE CWE DEFINITION IS NOT A “CLEAR” DEFINITION OF THE WEAKNESS, BUT IS A GENERAL STATEMENT ( I.E. “HOW” ARE STRING MANIPULATION FUNCTIONS EXPLOITED? AND ARE “ALL” STRING MANIPULATION FUNCTIONS EXPLOITABLE, OR JUST "SOME" OF THEM?) SO WE WROTE A CLEARER AND MORE SPECIFIC DEFINITION. WE AGREE THAT ANY ADDITIONAL “SUBSET” WEAKNESSES NEED TO BE DEFINED THROUGH DIALOG WITH MITRE.

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

NIST: WE AGREE THAT TAINTEDNESS IS NOT A PREREQUISITE TO AN OVERFLOW, AND WE ARE REMOVING THAT WORDING FROM OUR DEFINITIONS.

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

NIST: WE AGREE THAT A WEAKNESS CAN BE VIEWED IN MANY DIFFERENT CONTEXTS ( TAINTED DATA, RANGE ERROR ETC.. ) AGAIN, THIS IS AN ISSUE TO BE TAKEN UP WITH CWE. HOWEVER, WE ARGUE THAT THERE MAY NOT BE A SINGLE CATEGORY FOR A WEAKNESS.

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

NIST: AGREED AND CHANGED TO CWE DEFINITION. 

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

NIST: WE DON'T KNOW.

-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