[CD] Reconsidering "split-by-default" in content decisions

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

Following is a writeup of some rationales for a new approach I plan on
taking with respect to some content decisions.  This will be discussed
in more detail at the CVE Board meeting.

The short intro is: in mid-2000, Editorial Board members suggested
adopting a "split-by-default" approach for handling closely related
candidates.  For example, if you're not sure whether you should create
1 candidate or 2, then create 2 if you don't have conclusive
information.

The short thesis is: Split-by-default doesn't work very well for CVE.

It's just an accident that the first examples are in Cisco products
(seriously), but maybe Andy Balinsky and Kevin Ziese can give us some
insider feedback.  Similarly for David LeBlanc, as some Microsoft
examples follow.

This writeup discusses CD:SF-LOC, which covers multiple bugs in the
same executable.  However, the same principles could be applied to
CD:SF-EXEC, which covers the same apparent bug appearing in multiple,
closely related executables.

- Steve


---------------------------------------------------------------------
CD:SF-LOC in action - present and past
---------------------------------------------------------------------

Consider these candidates:

======================================================
Candidate: CAN-2001-0019
Proposed: 20010202
Reference: ATSTAKE:A013101-1
Reference: URL:http://www.atstake.com/research/advisories/2001/a013101-1.txt
Reference: CISCO:20010131 Cisco Content Services Switch Vulnerability
Reference: URL:http://www.cisco.com/warp/public/707/arrowpoint-cli-filesystem-pub.shtml

Arrowpoint (aka Cisco Content Services, or CSS) allows local users to
cause a denial of service via a long argument to the "show script,"
"clear script," "show archive," "clear archive," "show log," or "clear
log" commands.


======================================================
Candidate: CAN-2001-0020
Proposed: 20010202
Reference: ATSTAKE:A013101-1
Reference: URL:http://www.atstake.com/research/advisories/2001/a013101-1.txt
Reference: CISCO:20010131 Cisco Content Services Switch Vulnerability
Reference: URL:http://www.cisco.com/warp/public/707/arrowpoint-cli-filesystem-pub.shtml

Directory traversal vulnerability in Arrowpoint (aka Cisco Content
Services, or CSS) allows local unprivileged users to read arbitrary
files via a .. (dot dot) attack.


----------------

I view these as different, since one involves accessing files via
.. directory traversal (one type of bug), and another involves
effectively a buffer overflow.  There are clearly 2 different places
in the code in which some error occurs.

While it's the same product in both cases, they're effectively 2
different types of bugs, so we create separate candidates.  This
approach is generally in line with how others distinguish between
vulnerabilities.

This is a good example of the application of the CD:SF-LOC (software
flaws in different lines of code) content decision.  Below are the
affected bullets from that CD:

>The "trigger code" is the specific line in the source code whose
>execution affects the system's security.  For example, the trigger
>code for a buffer overflow might be a call to the strcat() function
>which causes the overflow and overwrites a stack pointer
>
> [...]
>
>*2) If it can be proven that the trigger code for P1 is different than
>    the trigger code for P2, then P1 and P2 must remain SPLIT.
>
> [...]
>
>6) If the method of exploitation for P1 is significantly different
>   from the exploitation of P2, then P1 and P2 should be SPLIT.  For
>   example, P1 might appear to be a buffer overflow that is caused by
>   sending a long command line argument, whereas P2 might follow
>   symbolic links improperly.

So, we've got sufficient reason to separate the apparent buffer
overflow from the .. directory traversal problem.

However, note that CAN-2001-0019 involves a DoS that is visible
through the execution of 6 different commands; the exploit and the
result are basically the same.

However, CAN-2001-0019 could be 1, 2, or 6 separate bugs, depending on
the actual source code.

For example, perhaps the piece of code that processes a "show" command
is different than the code that processes a "clear" command.
Internally, the code might look something like:

   if (strcmp(cmd, "show") == 0)
   {
      /* Buffer overflow 1 */
      strcpy(str, long_cmd_argument);
      process_show_command(str);
   }
   elsif (strcmp(cmd, "clear") == 0)
   {
      /* Buffer overflow 2 */
      strcpy(str, long_cmd_argument);
      process_clear_command(str);
   }

If the above code is what's "really" going on within the Cisco source
code, then one could say that there are 2 different buffer overflows.

But then again, the source code could be:

   /* Buffer overflow 1 */
   strcpy(arg, long_cmd_argument);
   if (strcmp(cmd, "show") == 0)
   {
     process_show_command(arg);
   }
   elsif (strcmp(cmd, "clear") == 0)
   {
     process_show_command(arg);
   }

in which case there's only one point in the code where the overflow
occurs.

But even still, the code could be:

   if (strcmp(cmd, "show") == 0)
   {
     if (strcmp(arg1, "script") == 0)
     {
         /* Buffer overflow 1 */
         strcpy(arg2, long_cmd_argument);
         show_script(arg2);
     }
     elsif (strcmp(arg1, "archive") == 0)
     {
         /* Buffer overflow 2 */
         strcpy(arg2, long_cmd_argument);
         show_archive(arg2);
     }
     elsif (strcmp(arg1, "log") == 0)
     {
         /* Buffer overflow 3 */
         strcpy(arg2, long_cmd_argument);
         show_log(arg2);
     }
   }
   elsif (strcmp(cmd, "clear") == 0)
   {
     if (strcmp(arg1, "script") == 0)
     {
         /* Buffer overflow 1 */
         strcpy(arg2, long_cmd_argument);
         show_script(arg2);
     }
     elsif (strcmp(arg1, "archive") == 0)
     {
         /* Buffer overflow 2 */
         strcpy(arg2, long_cmd_argument);
         show_archive(arg2);
     }
     elsif (strcmp(arg1, "log") == 0)
     {
         /* Buffer overflow 3 */
         strcpy(arg2, long_cmd_argument);
         show_log(arg2);
     }
   }


If this is the case, then there are 6 different buffer overflows.

So, depending on the actual source code, we have either 1, 2, or 6
overflows.

Ideally, we'd want to create a separate CAN for each separate bug.
However, we don't have access to the source code, so we can't tell for
sure.  The vendor could tell us, but what if they believe it's only 1
problem, even if our content decisions say it would be 6?

Last August, the Editorial Board said: "when in doubt, SPLIT,"
i.e. create separate candidates unless you have solid proof that the
issues really stem from the same vulnerable line of code.

So, I went ahead and started separating candidates.  But this did
several things:

1) CVE's level of abstraction (LOA) started becoming a lower level
   than the LOA of other security databases and tools.  In general,
   CVE should probably live somewhere in the middle.

2) The LOA definitely started getting too low level for system
   administrator purposes.  For example, a sysadmin doesn't
   necessarily care whether there's 1 buffer overflow or 5, it's more
   important to know that a particular package has a problem.

   While system administrators aren't the only type of CVE user out
   there, they are definitely a major user community, so we should be
   mindful of them.

3) The LOA would vary depending on the amount of information that was
   available, e.g. source code or detailed exploit information.
   Generally, the more information that was available, the more
   candidates you'd create for closely related issues.

   Effectively, we wind up penalizing those vendors with open source
   code, or those who are more closely analyzed.  We also end up
   "helping" vendors who release little or no information at all.
   This seems backwards.

4) Since "SPLIT by default" is effectively arbitrary, it's probably
   going to be wrong half the time.  Because we're affected by the
   amount of available information as described in (3) above,
   split-by-default won't be consistently applied to every
   vulnerability.

5) It gets more difficult to write descriptions that adequately
   differentiate between closely related bugs.

   For example, in OpenBSD, you might have a bug in stdio.c in line
   340; but that same bug is in line 476 in stdio.c in FreeBSD, and
   it's in line 78 in file somethingelse.c in Linux.

The poster children for problems 1, 2, 3, and 4 are CAN-2000-1081
through CAN-2000-1088, which describe buffer overflows that are
*triggered* through different functions in Microsoft SQL Server.  Each
function got its own candidate.  However, there could be a single
point of failure in a piece of code that's shared by all those
functions, so maybe it's only 1 bug.  Also, all the bugs happen in SQL
Server.  From a sysadmin's perspective, there's only one major point
of concern - vulnerable SQL Server - instead of 8 concerns, which
argues for 1 candidate.

The poster children for problem 5 are format string problems, which
generally seem to be found and fixed in bunches.  Since various Unices
are doing the fixing, and each Unix has a slightly different code
base, identifying and differentiating these becomes near impossible
and would require close code evaluation of each affected OS to be
accurate.

So, I'm backing off of the split-by-default suggestion, and adopting a
more consistent approach that's less susceptible to lack of
information, "politics," and deep analysis, and is more in line with
what I've generally seen in other databases:

1) Create separate candidates for separate types of bugs, e.g. buffer
   overflows versus .. problems.

2) If P1 and P2 are the same type of bug, *and* they are both present
   in the same version of software, *and* they are both fixed by the
   same version (if fixes are available), then create a single
   candidate for them.

3) If there's a possibility that there are multiple similar bugs as
   seen through (2), then try to clearly distinguish them in the CVE
   description, so people will know that it could be multiple bugs.

4) Make the content decisions more directly available to the public,
   and annotate each CVE item with its associated CD's, so that users
   can tell which CVE items might be at an "incorrect" level of
   abstraction.

Now, the challenge will be actually discussing this at the
face-to-face meeting in March :-)

- Steve


======================================================
Candidate: CAN-2000-1081
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1081
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2030
Reference: URL:http://www.securityfocus.com/bid/2030

The xp_displayparamstmt function in SQL Server and Microsoft SQL
Server Desktop Engine (MSDE) does not properly restrict the length of
a buffer before calling the srv_paraminfo function in the SQL Server
API for Extended Stored Procedures (XP), which allows an attacker to
cause a denial of service or execute arbitrary commands, aka the
"Extended Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_displayparamstmt,
xp_enumresultset, xp_showcolv, and xp_showcolv should be separate.
However, CD:SF-LOC is still under discussion by the Editorial Board,
so these may be MERGED together.


======================================================
Candidate: CAN-2000-1082
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1082
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2031
Reference: URL:http://www.securityfocus.com/bid/2031

The xp_enumresultset function in SQL Server and Microsoft SQL Server
Desktop Engine (MSDE) does not properly restrict the length of a
buffer before calling the srv_paraminfo function in the SQL Server API
for Extended Stored Procedures (XP), which allows an attacker to cause
a denial of service or execute arbitrary commands, aka the "Extended
Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_displayparamstmt,
xp_enumresultset, xp_showcolv, and xp_showcolv should be separate.
However, CD:SF-LOC is still under discussion by the Editorial Board,
so these may be MERGED together.


======================================================
Candidate: CAN-2000-1083
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1083
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2038
Reference: URL:http://www.securityfocus.com/bid/2038

The xp_showcolv function in SQL Server and Microsoft SQL Server
Desktop Engine (MSDE) does not properly restrict the length of a
buffer before calling the srv_paraminfo function in the SQL Server API
for Extended Stored Procedures (XP), which allows an attacker to cause
a denial of service or execute arbitrary commands, aka the "Extended
Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_displayparamstmt,
xp_enumresultset, xp_showcolv, and xp_showcolv should be separate.
However, CD:SF-LOC is still under discussion by the Editorial Board,
so these may be MERGED together.


======================================================
Candidate: CAN-2000-1084
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1084
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2039
Reference: URL:http://www.securityfocus.com/bid/2039

The xp_updatecolvbm function in SQL Server and Microsoft SQL Server
Desktop Engine (MSDE) does not properly restrict the length of a
buffer before calling the srv_paraminfo function in the SQL Server API
for Extended Stored Procedures (XP), which allows an attacker to cause
a denial of service or execute arbitrary commands, aka the "Extended
Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_displayparamstmt,
xp_enumresultset, xp_showcolv, and xp_showcolv should be separate.
However, CD:SF-LOC is still under discussion by the Editorial Board,
so these may be MERGED together.


======================================================
Candidate: CAN-2000-1085
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1085
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2040
Reference: URL:http://www.securityfocus.com/bid/2040

The xp_peekqueue function in Microsoft SQL Server 2000 and SQL Server
Desktop Engine (MSDE) does not properly restrict the length of a
buffer before calling the srv_paraminfo function in the SQL Server API
for Extended Stored Procedures (XP), which allows an attacker to cause
a denial of service or execute arbitrary commands, aka the "Extended
Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_peekqueue,
xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should
be separate.  However, CD:SF-LOC is still under discussion by the
Editorial Board, so these may be MERGED together.


======================================================
Candidate: CAN-2000-1086
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1086
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2041
Reference: URL:http://www.securityfocus.com/bid/2041

The xp_printstatements function in Microsoft SQL Server 2000 and SQL
Server Desktop Engine (MSDE) does not properly restrict the length of
a buffer before calling the srv_paraminfo function in the SQL Server
API for Extended Stored Procedures (XP), which allows an attacker to
cause a denial of service or execute arbitrary commands, aka the
"Extended Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_peekqueue,
xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should
be separate.  However, CD:SF-LOC is still under discussion by the
Editorial Board, so these may be MERGED together.


======================================================
Candidate: CAN-2000-1087
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1087
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2042
Reference: URL:http://www.securityfocus.com/bid/2042

The xp_proxiedmetadata function in Microsoft SQL Server 2000 and SQL
Server Desktop Engine (MSDE) does not properly restrict the length of
a buffer before calling the srv_paraminfo function in the SQL Server
API for Extended Stored Procedures (XP), which allows an attacker to
cause a denial of service or execute arbitrary commands, aka the
"Extended Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_peekqueue,
xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should
be separate.  However, CD:SF-LOC is still under discussion by the
Editorial Board, so these may be MERGED together.


======================================================
Candidate: CAN-2000-1088
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1088
Phase: Proposed (20001219)
Category: SF
Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2
Reference: MS:MS00-092
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp
Reference: BID:2043
Reference: URL:http://www.securityfocus.com/bid/2043

The xp_SetSQLSecurity function in Microsoft SQL Server 2000 and SQL
Server Desktop Engine (MSDE) does not properly restrict the length of
a buffer before calling the srv_paraminfo function in the SQL Server
API for Extended Stored Procedures (XP), which allows an attacker to
cause a denial of service or execute arbitrary commands, aka the
"Extended Stored Procedure Parameter Parsing" vulnerability.

Analysis
----------------
Vendor Acknowledgement: yes advisory
Content Decisions: SF-LOC

ABSTRACTION:

CD:SF-LOC suggests having separate items, one for each buffer overflow
in each separate "line of code."  Thus xp_peekqueue,
xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should
be separate.  However, CD:SF-LOC is still under discussion by the
Editorial Board, so these may be MERGED together.