[CD] CD Proposal: SF-EXEC (Software flaws in multiple executables)

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

The following content decision (CD) is related to cases in which the
same software flaw appears in multiple executables within the same
software package.

CD Proposal Date: 6/12/2000
Voting Period: 7/10/2000
Final Decision: 7/24/2000


************************************************************************
CD:SF-EXEC (Software flaws in multiple executables)
************************************************************************
Type: ABSTRACTION
Version: 1.0
Proposed: 6/12/2000
Final Decision: N/A



Short Description
-----------------

If the same software flaw appears in multiple executables in the same
package, then record it in a single entry.


Definitions
-----------

All definitions are informal.

A "software package" is loosely defined as a collection of software
that is normally bundled together, provides a single overall
capability, and is offered on the same platform by a single vendor, or
for multiple platforms by the same developer.


Affected Candidates
-------------------

All active candidates that are affected by this content decision can
be obtained via the following URL:

   http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CD:SF-EXEC


Application
-----------

If a * appears before a CD item, then if that item applies to P1 and
P2, then the remainder of the CD should not be applied.

Note: this CD is closely related to CD:SF-LOC and CD:SF-CODEBASE.
CD:SF-EXEC intersects with CD:SF-LOC with respect to software flaws
that occur in libraries, because a library bug may appear in multiple
executables, and the exploitation of that bug may vary depending on
the executable.  CD:SF-EXEC intersects with CD:SF-CODEBASE if a
software package is offered by multiple vendors, but a portion of its
codebase originates from a single developer.

Consider a problem P1 in an executable E1, and a problem P2 in a
different executable E2.

*1) If E1 and E2 are not in the same software package, then this CD
    does not apply.

*2) If P1 and P2 do not exist at the same time (i.e. are not in the
    same package "version"), then they must remain SPLIT.

*3) If P1 and P2 are not fixed by the same patch or set of patches,
    then they must remain SPLIT.

4) If the method of exploitation for P1 and P2 is the same (with the
   exception of which executable is exploited), and the results of the
   exploitation are the same, then P1 and P2 should be MERGED.

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

6) If P1 and P2 are fixed by the same patch, and there is no evidence
   that they require different exploitation methods, then they should
   be MERGED.

7) If there is strong evidence that P1 is an exact copy of the source
   code used by P2 (e.g. in a cut-and-paste operation by the same
   developer), or P1 and P2 were introduced by the same individual at
   the same time, then P1 and P2 should be MERGED.

8) If there are conflicting recommendations from previous items in
   this CD, then the first item that applies should be used to
   determine whether P1 and P2 should be SPLIT or MERGED.

9) If no item in this CD (besides this one) suggests whether P1 and P2
   should be MERGED or SPLIT, then they should be MERGED.


Guidance
--------

If E1 and E2 may share the same library, and P1 and P2 look similar,
then make sure to apply CD:SF-LOC, which covers libraries.



Examples
--------

*********************************************

CAN-1999-0840: Buffer overflow in CDE dtmail and dtmailpr programs via
the -f option.

Should dtmail and dtmailpr be SPLIT into separate entries, or should
we keep them MERGED?

SF-EXEC.2 and SF-EXEC.3 do not apply.

SF-EXEC.4 - MERGE.  Overflow is in -f command line option, and the
same EIP is returned according to UNYUN

SF-EXEC.5 - does not apply

SF-EXEC.6 - MERGE.  Same patch fixes both problems.

SF-EXEC.7 - does not apply.  There is not strong evidence, because we
    do not have the source code.


Since dtmail and dtmailpr may have the same bug, we need to examine
this using CD:SF-LOC as well.


*********************************************

CAN-1999-0840 and CAN-1999-0841

CAN-1999-0841: Buffer overflow in CDE mailtool allows local users to
gain root privilege via a long MIME Content-Type.

Should we MERGE CAN-1999-0840 and CAN-1999-0841?  They were both
discussed in the same Bugtraq posting, and they both have the same
Bugtraq ID.


dtmail, dtmailpr, and mailtool all have similar software
functionality.  But mailtool is in the OpenWindows environment,
according to UNYUN's post, whereas dtmail and dtmailpr are for CDE.
So they are in different software packages, so SF-EXEC.1 says to keep
them SPLIT.

Let's suppose that these *are* in the same package anyway.  Then
SF-EXEC.2 does not apply.  These are not fixed by the same patch, so
SF-EXEC.3 would require that we SPLIT them.  But let's go one step
further, and suppose that these are fixed by the same patch.

The buffer overflow for dtmail/dtmailpr is via a -f command line
option, and mailtool is via a long Content-Type: mail header.  The
method of exploitation is different, so SF-EXEC.4 does not apply, but
SF-EXEC.5 suggests that we SPLIT.  SF-EXEC.6 does not apply, and
neither does SF-EXEC.7.

So, all recommendations suggest a SPLIT.  So we will keep
CAN-1999-0840 and CAN-1999-0841 separated.

*********************************************


CAN-1999-0736, 0737, 0738, 0739.  (various vulnerable .asp files in
IIS/Site Server).

These all *could* be due to the same flaw in a library function, so we
should consider applying CD:SF-LOC.  But each .ASP is a different
executable, so we need to examine it from the CD:SF-EXEC perspective
as well.

[NOTE: since it's not a library problem, SF-LOC doesn't really apply,
so the following text makes it more complicated than it needs to be.
*If* Microsoft had "fixed" the server.mappath function, then it would
be a library function, and SF-LOC *would* apply.  But it's not a
library problem and there are different executables, so we use SF-EXEC
instead.]

CAN-1999-0737 (viewcode.asp) has different KB articles than the
others, and only Site Server is affected (the others have IIS and Site
Server).  Each .asp has different source code patches, so CD:SF-LOC.4
says that these candidates should remain SPLIT; however, the hotfix is
the same, so CD:SF-LOC.4 doesn't apply if we consider the hotfix to be
the patch.

SF-LOC.6 clearly doesn't apply because there are separate patches for
each .ASP file, so it's not a library.  BUT, the KB article for 0737
says that ViewCode.asp 'uses "server.mappath" without any restrictions
on what is passed to this function' and the KB article for the others
uses this same description.  So, *if* the patch had involved modifying
the server.mappath function, then this function would be like a
library function, and all the different candidates would be merged via
SF-LOC.2.

CD:SF-EXEC also applies here, but again we must decide what we mean by
"patch."  If we consider the source code modifications to be the
patches, then SF-EXEC.3 suggests that we should keep these candidates
SPLIT.  But if we regard the hotfix as the patch, SF-EXEC.3 doesn't
apply.  SF-EXEC.4 and SF-EXEC.6 apply and suggest a MERGE.


*********************************************

CAN-1999-0435: MC/ServiceGuard and MC/LockManager in HP-UX allows
local users to gain privileges through SAM.

SF-EXEC.2 does not apply. In most cases, including the most recent
affected release, different patches are required for these programs,
so SF-EXEC.3 suggests SPLIT.  Exploits are unknown, so .4 and .5 do
not apply, although the vague description suggests that .4 might apply
as a MERGE.  SF-EXEC.6 does not apply because the patches are
different.  SF-EXEC.7 does not apply due to lack of evidence.

"Common sense" says that these should probably be MERGED, but due to
the lack of information suggesting otherwise, SF-EXEC.3 suggests
SPLIT.

Perhaps we should have a general approach to MERGE in cases where: (a)
the executables are in the same software package; (b) patches are
provided at the same time; (c) there is very little information
available otherwise.  On the other hand, this approach could unfairly
reduce the number of CVE entries for vendors who do not provide
technical details.


*********************************************

CAN-1999-0467 (Webcom guestbook, wguest.exe and rguest.exe)

CD:SF-EXEC.3 is unknown. SF-EXEC.4 suggests MERGE.  SF-EXEC.5 and
SF-EXEC.6 do not apply.  SF-EXEC.7 suggests MERGE.

So, keep these MERGED.

*********************************************

CAN-2000-0213 (Sambar server, ECHO.BAT and HELLO.BAT both call "echo"
and support metacharacters).

SF-EXEC.4, SF-EXEC.6, and SF-EXEC.7 suggest MERGE.  The "patch" is to
delete the batch files, both of which contain the same vulnerable
"echo" command.


*********************************************
CAN-2000-0163 (FreeBSD asdmon and ascpu).

asdmon and ascpu are similar-looking, but different packages that
appear to be by different developers.  Details are a little sketchy,
and there isn't much information out there for either of these third
party programs, but it appears that the bug is in how FreeBSD ported
the software.  The FreeBSD advisory says it's similar to a problem in
their port of wmmon (CAN-2000-0018), which would read a
user-modifiable configuration file which defined commands that would
be executed upon certain mouse events.  The problem is that it was
setgid kmem; privileges weren't necessary for the original Linux
versions, so this was a bug in FreeBSD's port of the software.  Since
FreeBSD made the same mistake again in 2 different packages, it's
reasonable to separate these out.  The "as" prefix for the programs
appears to be related to the specific window/display manager they were
written for.

Since these are not fixed by the same patch, CD:SF-EXEC.3 dictates
that this candidate should be SPLIT.  If SF-EXEC.3 weren't applicable,
then there's no other real solid evidence for or against a SPLIT, so
the default would then be to MERGE.



Dissenting Opinions
-------------------

Upon approval of this CD, this section will include a summary of any
dissenting opinions.