[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Rootkit RE: [PROPOSAL] DDOS - Distributed DoS (1 candidate)

Just a thought,

Maybe we should spend some time considering all the underlying state
transitions involved for these different attacks a/o tools a/o
vulnerabilities and then construct some CVE entries based on the state
transitions involved, instead of specifically named, and constantly
changing, attack methodologies a/o tools.

Kevin

> -----Original Message-----
> From: owner-cve-editorial-board-list@lists.mitre.org
> [mailto:owner-cve-editorial-board-list@lists.mitre.org]On Behalf Of
> Aleph One
> Sent: Wednesday, February 16, 2000 10:50 AM
> To: Pascal Meunier; cve-editorial-board-list@lists.mitre.org
> Subject: Re: Rootkit RE: [PROPOSAL] DDOS - Distributed DoS (1 candidate)
>
>
> On Wed, Feb 16, 2000 at 09:28:35AM -0500, Pascal Meunier wrote:
> > 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.
>
> 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
>
> --
> Aleph One / aleph1@underground.org
> http://underground.org/
> KeyID 1024/948FD6B5
> Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01
>
>
Page Last Updated or Reviewed: May 22, 2007