THIS CANDIDATE HAS GENERATED A LONG THREAD. SEE THE
EDITORIAL BOARD ARCHIVES FOR DETAILS, BEGINNING AT
I suggest we I'd like to suggest that we consider not tying
specifically to a DDOS tool. Instead, since we are at at higher
abstraction level, that we make the class include those master/slave
tool combinations that are used for malicious purposes (i.e. DDOS,
data exfiltration, or whatever the appropriate classes of effect are).
My concern is that (1) we treat all distributed attacks at the same
abstract level; not just the DDOS ones. Second, if it is at a higher
abstraction level then it seems right to unlimit it (by including
master/slave combinations in general; not just the DDOS asect).
Meunier> I think that trinoo etc... are very similar to smurf attacks
(CVE-1999-0513 ) in the sense that a third party allows itself to be
used. Also, there is an obvious solution that can only be done by
that third party.
As for the CVE entry, I am considering whether the common entry point
could be reduced to "egress filtering has not been implemented or has
been disabled, allowing the sending of spoofed IP packets".
Incidentally, this would prevent the use of decoys in port scans,
etc... This single CVE entry would be very powerful. We could use
the dot notation to list the DDoS tools and attacks that rely on the
absence of egress filtering based on the argument that if you have
egress filtering, nobody will bother to put or use DDoS tools on your
The weakness of this is that one could in theory still use DDoS tools
even if you have egress filtering -- only they will be one shot guns,
almost completely eliminating their appeal and effectiveness. One
use, and they will be blocked, tracked down and destroyed
P.S.: I am attracted by the idea of starting an internet (fire)wall
of shame, for people who haven't implemented egress filtering. It
worked pretty well against sites allowing themselves to be used for
smurf attacks (http://www.powertech.no/smurf/). Why not use the same
strategy for egress filtering? Of course it's hard to know who is
the source of IP spoofed packets. However the consistent detection
of crud originating from a server is a sure sign that they haven't
implemented egress filtering. For example (my first candidate to
this wall of shame), this weekend the Linux suse ftp server sent many
packets with an illegal ip address as source, one reserved for local
area networks, upon making an ftp connection (it may still be doing
it, I haven't checked since -- the suse ftp admin mentioned that they
were aware of it). It was easy to figure out it was them by
repeating the ftp connections and observing the 100% reproducibility
and time correlation of the extraneous packets. In addition, the
suse servers kept sending me crud for *hours* after a failed attempt
to download their PPC beta.
The cost of egress filtering is easily justified. The argument is
similar to those relating to pollution, excepted that people don't
try to break into your car if you have removed the catalytic
Bishop> I need to think about the exact meaning of MP. I suspect I
will agree with the classification, on an operational basis
(meaning I may want to revisit it), but I want to think on it
Blake> I don't agree with Pascal that this is a filtering problem analogous to
smurf. Rootkit is a better analogy. The DDoS software doesn't exploit
any unique vulnerability directly. It's presence is entirely predicated
on the existence of at least one other, easily exploited vulnerability.
>From the perspective of the system owner, this is just one of several
backdoors that could be installed. Seems to me that the presence of a
known backdoor package should be considered a vulnerability (or at least
I'm really torn on whether or not to split them out, though. My
inclination is to group master and slave by package; i.e., trinoo
master/slave, tfn master/slave, etc.
Just to be consistent, you may add Trinoo (trin00) and does it matter
if it is Tribal or Tribe? The original internal c program says Tribe Flood
Meunier> What they have in common is the use of an amplification mechanism.
They are broadcasting (multicasting) to a (virtual private) network,
which then amplifies the messages. In both cases, the amplification
is done by the third party victim hosts. The difference is just that
the network is virtual instead of physical.
Scott, you are assuming that the people who have the tools installed
are unwilling. Let's say theoretically speaking that there is an
underground hacker group (or student association) who is hooked up to
DSL lines (like in university residences) and who thinks that it
would be "cool" to form an "army". How about a popular civil
movement protesting something, like the WTO last summer? I think
some people would voluntarily "enlist" their computers in a cause
that would use DDoS attacks. The rootkit analogy does not hold, yet
the DDoS attacks could be just as effective. However, if the
university or ISPs implemented egress filtering, the DDoS attacks
could be easily stopped because the people could be held accountable.
The crux of the matter is the anonymity provided by IP spoofing.
You are correct that in most cases, having a DDoS tool installed on
your system is an exposure like rootkit. Maybe that deserves a CVE
entry. However, I think that does not capture the nature of the
DDoS, and that an entry about egress filtering is of utmost
importance because it patches a fundamental vulnerability of IPv4.
Blake> Excellent response, Pascal, thanks. I hadn't thought of people
volunteering, but that's certainly a plausible scenario. Part of my
motivation/thinking was a desire to stay away from making this into only
yet another use for spoofed IP packets. I wholeheartedly agree that
egress filtering essential, but am reluctant to single out the recent DDoS
events as the reason for it.
I'd prefer to split out egress filtering as a seperate CVE entry (on the
theory that not using egress filtering constitutes an exposure -- at least
to liability), rather than tying it to these entries.
Levy> I agree with Scott for no other reason that there needs to be a CVE
ID so that IDS systems can report this things.
Are we going to start handing out CVE ids for low level design faults?
E.g. lack of encryption at the IPv4 packet level? lack of resource
allocation protocols? the used of DES instead of Triple DES? etc
Shostack> Both excellent points, however, I'd like to add that even if people
volunteer to host the tools, Trinoo and company allow the controlling
attacker to hide activities, which counts as an exposure under
Cole> Even with all of the debate i accept this one.
Christey> With respect to inclusion of design flaws in CVE, review
Other design flaws that have already been added to CVE
include Smurf (CVE-1999-0513), Fraggle (CVE-1999-0514)
and TCP sequence number prediction (CVE-1999-0077), although
this last one may need to be RECAST to a lower level of
CHANGE> [Meunier changed vote from REVIEWING to RECAST]
Meunier> In the sense that this is like a rootkit, then it is a
duplicate of CVE-1999-0660, "A hacker utility or Trojan Horse is
installed on a system, e.g. NetBus, Back Orifice, Rootkit, etc..."
It should be recast as CVE-1999-0660.1 DDoS tools
Other dot notations could indicate different effects of the tools.
Dik> There doesn't seem to be much to add to the
Baker> Concur that this is a hacker utility, and should be recast and merged with other backdoor programs that allow a hacker to control the activities of the system.