RE: Discussion point: CONSPEC - Context-specific Issues

I very much agree with the recommendation here.
These nodes should stay where they are but potentially have their descriptions tweaked to explain any context-specific characteristics.

Sean Barnum

-----Original Message-----
From: owner-cwe-research-list@... [mailto:owner-cwe-research-list@...] On Behalf Of Steven M. Christey
Sent: Monday, September 17, 2007 8:06 PM
To: CWE-RESEARCH-LIST@...
Subject: Discussion point: CONSPEC - Context-specific Issues

Below is the current writeup for Context-specific issues, as also seen
on the CWE web site:

  http://cwe.mitre.org/community/research/discussion/conspec.html

A list of potentially affected nodes is here, although I see that the
list is incomplete and has a couple items that don't belong (I'll work
to clean it up):

  http://cwe.mitre.org/community/research/discussion/reports/rpt-conspec.html

Please review the potential solutions and let us know if our
recommendations will work for you (or not).

In a separate post, I'll provide a detailed writeup of the kinds of
changes that would be made to the CWE nodes, based on the topics
listed in this discussion point.

Please post your comments to this list.


Thank you,
Steve


================================
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 [45]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:

  http://cwe.mitre.org/community/research/discussion/reports/rpt-conspec.html