Common Weakness Enumeration

CWE Glossary Definition

CONSPEC: Context-specific Issues
CONSPEC: Context-specific Issues

Some issues are generally thought of to be "bad practice" or misuse, but they can be used in certain contexts that are perfectly legitimate.

Examples:

CWE-481 - Assigning instead of comparing
CWE-482 - Comparing instead of assigning
CWE-486 - Comparing Classes by Name
CWE-568 - Erroneous Finalize Method
CWE-572 - Calling Thread.run() instead of Thread.start()
CWE-597 - Erroneous String Compare

Code:

	char * a,b;
	...
	if (a == b) {...} /* 1 */
	if (! strcmp(a,b)) {...} /* 2 */

Issue 1: Inclusion

Any possible security-related impact of these issues is dependent on the context and policy of their use. CWE-597 might be flagged as an issue, as in the above code, but it really depends on the context and the programmer's intent. Comparing strings using == is only problematic if the programmer meant to compare the strings and not their pointers. Likewise, just because strcmp() is used in the context of comparing two char *, it does not mean that the programmer didn't intend to compare the pointer references. Furthermore, in some languages, such as Python, == is the recommended way of testing string equivalence.

With CWE-572, there is no issue if the programmer intended for the run() function to operate in a synchronous context. Since these are hard to identify might depend on external operational contexts, they may lead to high false positive or false negative rates in detection and should not be included as a weakness.

With CWE-481, it is a common idiom to perform a variable assignment within a conditional. While this might be regarded as a risky practice, many such constructs are performed correctly, even if automated tools might flag them as unintentional comparisons.

Issue 2: Abstraction

It could be argued that these are all issues in which the programmer is not doing what is intended. Therefore, these might be restructured under a general context-specific grouping. Similarly, it could be argued that these are all function or language-specific issues and should be restructured or merged into that issue. Note: the mechanisms for node restructuring are still being defined.

Possible Solutions:

1) Abstract all context-dependent issues under a context-dependent parent to indicate the potential problems when dealing with these weaknesses, making the current CWEs its children.

2) Treat these as a case of language-specific issues.

3) Leave the context-dependent entries in place in CWE, incorporating caveats as to their use, and highlight context-dependent circumstances.

4) MERGE all context-dependent entries under a single abstract parent (see the node restructuring page for possible approaches).

Relevant Use-Cases

Assessment Vendors: Fairly easy to identify potential code issues, but hard to judge context and programmer intent. Nonetheless, they could be flagged for further analysis by a developer, although it could lead to a lot of false positives and/or false negatives.

Assessment Customers: Useful when interpreting potential issues flagged by vendors.

Educators: Identify common language mistakes and misinterpretations to use to highlight specific instances.

Academic Researchers: Identify ambiguous aspects of languages that allow programmers to misuse features, whether intentional or unintentional.

Applied Vulnerability Researchers: Pinpoint areas to look at as context can more easily be determined and problems identified, especially since the code scanners may make many mistakes and developer confusion/syntactic similarities could cause these issues to go unnoticed.

Refined Vulnerability Information (RVI) Providers: Not applicable.

Software Customers: Not applicable.

Software Developers: Help to identify certain context-dependent issues that are commonly missed and might require extra attention.

Recommendation

The CWE Researcher Community is strongly encouraged to provide feedback to the CWE team or the researchers list regarding this recommendation.

To provide stability, logical categorization, and maximize the overall usability by all of the potential CWE customers, the MITRE CWE team recommends to keep the current CWEs and their locations as they are. Any descriptions should be abstracted to remove language-specific inclinations where applicable, and any usage or context-specific caveats should be called out where necessary. These could be treated as examples of "sub-nodes." Note: the mechanisms for node restructuring are still being defined; see the node restructuring page for possible approaches.

For example, this would mean the CWE-597 (Erroneous String Compare) entry would be described as "strings should be compared by content and not by references." This means that functions like String.equals() (Java) and strcmp (C) should be used for string comparison, instead of == or !=. In some languages, like Python, comparing string contents is performed via ==, as might be expected. As a caveat, if the program is intending to compare string references or pointers, then == and != are the correct comparison operators.

Notes

Below is preliminary work done in order to more clearly identify problems present in CWE. Any issues not addressed above should be brought to the attention of the whole list, especially if the CWE ID is missing from the notes below.

Types of context-specific issues:

• failure to adhere to a tech-specific specification
  568, 574, 575, 576, 577, 578, 580, 581, 582, 583
• use of unsafe or error-prone constructs
  584, 586, 587, 588
• legitimate functionality that's only a security concern relevant in privileged or other limited contexts
  570, 571, 589, 595, 597, 598, 8, 9, 481, 482

Complete List of Examples

All CWE nodes that are affected by this discussion point are listed on a separate page.

Document version: 0.1    Date: September 13, 2007

This is a draft document. It is intended to support maintenance of CWE, and to educate and solicit feedback from a specific technical audience. This document does not reflect any official position of the MITRE Corporation or its sponsors. Copyright © 2007, The MITRE Corporation. All rights reserved. Permission is granted to redistribute this document if this paragraph is not removed. This document is subject to change without notice.