CONTENT DECISION: Presence of Services or Applications (SA)

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

The final set of candidate clusters touches on what I believe are the
most controversial content decisions with respect to the draft CVE,
since they are often related to enterprise-specific definitions of
"vulnerability."

The SA category is used to identify vulnerabilities where the simple
presence of a service or application is considered a CVE
vulnerability.  We have already seen a number of "SA" category
candidates in the DESIGN cluster such as finger, rexec, etc., where
the service runs as designed, but might be a vulnerability according
to some policies.  As Gene Spafford indicated previously, most SA
category problems may not be considered vulnerabilities in an academic
setting, but they might in a more restrictive context (e.g. classified
or other highly sensitive networks).

Many tools report a fair number of "checks" that reference SA-category
vulnerabilities.  Network scanners average about 25 services per tool.

The SA-* clusters reflect content decisions related to the final
bullet of the CVE vulnerability definition, which includes the use of
a service or application that:

> - (7) is a primary point of entry that an entity may attempt to use
>   to gain access to the system or data


Of course, any service could be regarded as a point of entry, thus it
is a High Cardinality problem to list all services.  However, there
are some services which are "more" of a concern than others, and thus
should be explicitly listed in the CVE because they satisfy bullet (7)
as given above.

Below are three content decisions related to SA Inclusion, i.e. when a
specific service/application should be individually named as a CVE
vulnerability.

1) Include services or applications that have a history of problems.

SMTP, FTP, HTTP, and other services have exhibited a number of
problems, either in the protocol itself, or there have been many
implementations which have had problems - consider Sendmail, wu-ftp,
or IIS, for example.  In some Conditional (enterprise-specific)
policies, running such software can be regarded as a vulnerability,
even if the software is configured correctly and is not believed to
contain any exploitable software flaws.

2) Include services that are common attack points.

Such services may not have a history of problems, but may be commonly
attacked because their compromise could provide significant benefits
to an attacker.  Consider NIS, SNMP, UUCP, rsh, etc., which have a
history of attacks but not too many different vulnerabilities.

3) Include "little" services that are rarely necessary in operations,
but are often useful to an attacker.

Examples include chargen, echo, systat.

- Steve