[PROPOSAL] DDOS - Distributed DoS (1 candidate)

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

With only one candidate, this "cluster" shatters the previous record
for smallest proposed cluster, which was 4.  But it's an interesting
candidate.

Given all the attention that has been paid to distributed denial of
service attacks from tools such as Trinoo, Tribe Flood Network, and
stacheldraht, and the extensive damage that has been done, there has
to be a vulnerability or exposure *somewhere*.  It has been a
challenge to couch this type of problem within CVE, which is the
reason that no Trinoo-related candidates were proposed before today.

On the one hand, how do you describe the problem in terms of a state
within a computing system or systems?  (See
http://cve.mitre.org/About_CVE/About/definition.html for a refresher
on the informal definitions that are being used).  Secondly, where is
the vulnerability - in the software? (and what software?)  In the
fundamental design of the Internet protocols?  Or is the vulnerability
that there are only finite resources available to handle high volumes
of traffic?  Or maybe there isn't a real "vulnerability" with DDOS -
rather, each agent/slave/zombie had to have been compromised using
*another* vulnerability, in order to act as valid users in such
attacks.  (This makes an assumption that the agents are not all owned
by the attacker.)

The candidate that is proposed below is at a higher level of
abstraction than most other CVE candidates or entries.  It's
effectively a catch-all for Trinoo, TFN, and their siblings.  Here's
why.

Informally within CVE, there is a category of "Malicious Presence"
(MP) which deals with the presence of malicious software on a system,
such as a Trojan Horse.  See the following messages posted to the
Board last summer:

http://cve.mitre.org/Board_Sponsors/archives/msg00343.html

http://cve.mitre.org/Board_Sponsors/archives/msg00344.html

DDOS utilities can be described in MP terms - namely, a master or
slave is running a DDOS utility.

The problem with Malicious Presence entries is one of scale.  Every
Trojan Horse that's out there constitutes a malicious presence.
Having a separate entry for each instance of MP would cause an
explosion in the size of CVE, significantly reducing its
maintainability as well as its use for most purposes.  The MP category
has a very high cardinality.  When you think of Trinoo and other DDOS
utilities, we may be able to identify all or most of them at this
point in time.  But I doubt we will be able to do so for long, as
various hybrids and enhancements are introduced.

Having a very high-level MP candidate seems "wrong" in that it "feels"
like it's at a different level of abstraction than other CVE entries.
The CD:HIGHCARD content decision suggests that in these cases, the
level of abstraction should be fixed at a higher level of abstraction.
While CD:HIGHCARD was voted for approval by the Board last summer, I
believe that it needs further discussion before a final decision is
made to use it.

See the following for more discussion:

http://cve.mitre.org/Board_Sponsors/archives/msg00258.html
http://cve.mitre.org/Board_Sponsors/archives/msg00263.html
http://cve.mitre.org/Board_Sponsors/archives/msg00271.html
http://cve.mitre.org/Board_Sponsors/archives/msg00275.html
http://cve.mitre.org/Board_Sponsors/archives/msg00380.html

The last link includes a writeup on CD:HIGHCARD.

Because of CD:HIGHCARD, the following candidate is proposed at a
higher level of abstraction than most.  But is the DDOS "class"
described in this candidate sufficiently distinguished by other MP
candidates?  See CAN-1999-0660 and CAN-1999-0661, which are also
affected by CD:HIGHCARD at:

http://cve.mitre.org/cgi-bin/cvename.cgi?CAN-1999-0660
http://cve.mitre.org/cgi-bin/cvename.cgi?CAN-1999-0661

Is there enough of a difference between a DDOS master and slave to
merit splitting this candidate?  Given that the language to describe
these types of entities is still evolving, what are the appropriate
terms to use?

- Steve


Summary of votes to use (in ascending order of "severity")
----------------------------------------------------------

ACCEPT - voter accepts the candidate as proposed
NOOP - voter has no opinion on the candidate
MODIFY - voter wants to change some MINOR detail (e.g. reference/description)
REVIEWING - voter is reviewing/researching the candidate, or needs more info
RECAST - candidate must be significantly modified, e.g. split or merged
REJECT - candidate is "not a vulnerability", or a duplicate, etc.

1) Please write your vote on the line that starts with "VOTE: ".  If
   you want to add comments or details, add them to lines after the
   VOTE: line.

2) If you see any missing references, please mention them so that they
   can be included.  References help greatly during mapping.

3) Note that a "MODIFY" is treated as an "ACCEPT" when counting votes.
   So if you don't have sufficient information for a candidate but you
   don't want to NOOP, use a REVIEWING.

********** NOTE ********** NOTE ********** NOTE ********** NOTE **********

Please keep in mind that your vote and comments will be recorded and
publicly viewable in the mailing list archives or in other formats.

=================================
Candidate: CAN-2000-0138
Published:
Final-Decision:
Interim-Decision:
Modified:
Proposed: 20000215
Assigned: 20000209
Category: MP
Reference: CERT:CA-2000-01
Reference: CERT:IN-99-04
Reference: SUN:00193
Reference: ISS:20000209 Denial of Service Attack using the TFN2K and Stacheldraht programs
Reference: BUGTRAQ:19991206 Analysis of trin00
Reference: BUGTRAQ:19991206 Analysis of Tribe Flood Network
Reference: BUGTRAQ:19991229 Analysis of "stacheldraht"
Reference: BUGTRAQ:20000211 DDOS Attack Mitigation
Reference: BUGTRAQ:20000211 TFN2K - An Analysis
Reference: BUGTRAQ:20000211 A DDOS proposal.

A system has a distributed denial of service (DDOS) attack master or
agent installed, such as Trinoo, Tribal Flood Network (TFN), Tribal
Flood Network 2000 (TFN2K), or stacheldraht.


VOTE: