CD PROPOSAL: Content Decisions for Software Flaws (Interim 8/30)

["Steven M. Christey" <coley@linus.mitre.org>]

I have taken the original 5 content decisions related to software
flaws and whittled them down to these three.

A significant number of candidates could be affected by these content
decisions, at least 100.  Rapid resolution will significantly help us
to have 300 accepted candidates by the SANS big splash.

Please vote to ACCEPT, MODIFY, or REJECT each content decision by the
scheduled Interim Decision of August 30.  I am providing these in the
same email in an attempt to reduce the traffic on this list.


VOTE
----

SF-LOC:
SF-CODEBASE:
SF-EXEC:



DESCRIPTIONS
------------


1) Different Line of Code, Different Vulnerability (SF-LOC)

   Distinguish between vulnerabilities that appear in the same
   program, but require different modifications to the source code to
   fix.  (Informally, distinguish between different bugs.)

2) Same Codebase, Same Vulnerability (SF-CODEBASE)

   Do not distinguish between vulnerabilities that have been derived
   from the same codebase, even if they appear on different platforms
   or software versions.  For vulnerabilities that affect multiple
   codebases, "roll up" the codebases into a single CVE entry, and use
   Dot Notation to identify each separate codebase.  This is done
   because separating codebases can be error-prone.  The dot notation
   allows the CVE to maintain accuracy, while providing the precision
   that is required of this content decision.  If the bug is in a
   library/DLL, then the software that uses that library is NOT
   discriminated, because the library is effectively the "same
   codebase."

3) Different Executables, Different Vulnerability (SF-EXEC)

   If a vulnerability appears in multiple executables which perform
   different functions, and it does not occur in a library that is
   shared by those executables, then distinguish them.  Executables
   are not distinguished by OS, except as dictated by SF-CODEBASE.

SF-CODEBASE and SF-EXEC may appear very similar.  The distinction is
that in SF-CODEBASE, we identify a "module" (e.g. program or
application) coming from a single source, where the affected portion
of that module has been preserved even as the module is modified over
the years by various vendors.  Each "module" covered by SF-CODEBASE
does effectively the same thing, functionally.

SF-EXEC covers the cases where a particular coding flaw might be
duplicated in multiple programs, e.g. by a cut-and-paste operation,
but each program does something functionally different.  Informally,
SF-CODEBASE separates two functionally similar programs when different
programmers made the same mistake.  SF-EXEC separates two functionally
different programs when different programmers (or even the same
programmer) made the same mistake in multiple places.


--------------------------------------------------------------------
EXAMPLES
--------------------------------------------------------------------


SF-LOC
------

Consider the ColdFusion vulnerabilities related to the Expression
Evaluator.  An "include" file used by multiple ColdFusion pages
allowed an attacker to read or delete files.  SF-CODEBASE says not to
distinguish between the different ColdFusion pages, since the include
file is effectively a library.  However, a different capability (not
provided in that include file) allows a remote attacker to execute
commands by uploading a file.  This is a different line of code, thus
a different vulnerability.


SF-CODEBASE
-----------

Consider a buffer overflow in various email clients that decode
MIME-formatted messages.  A number of clients were affected, including
Solaris mailtool, Mutt, Pine, and Outlook.  Since all four are
conceivably from different codebases, a CVE entry might be created as
follows:

>Buffer overflow in MIME-compliant email clients, including:
>
> 1. Solaris mailtool
> 2. Mutt
> 3. Pine
> 4. Outlook

On the other hand, the TERM environmental variable buffer overflow in
the rlogin program affected many platforms.  But the rlogin program
was originally written by a single author, thus each instance of
rlogin comes from the Same Codebase.  So, the associated CVE entry
might simply say "Buffer overflow using TERM environmental variable in
rlogin" without specifying the affected OSes.


SF-EXEC
-------

Consider the buffer overflows in the SGI IRIX df, ordist,
login/scheme, eject, and pset commands.  Each was discovered and
patched at a different time, thus they clearly did not share the same
library (in which SF-CODEBASE would require combining them).  They are
different executables that perform different tasks, thus SF-EXEC
requires that a separate entry be made for each one.