CVE List
| Id | CVE No. | Status | Description | Phase | Votes | Comments | Actions |
|---|---|---|---|---|---|---|---|
| 1716 | CVE-2000-0138 | Candidate | A system has a distributed denial of service (DDOS) attack master, agent, or zombie installed, such as (1) Trinoo, (2) Tribe Flood Network (TFN), (3) Tribe Flood Network 2000 (TFN2K), (4) stacheldraht, (5) mstream, or (6) shaft. | Modified (20130104-02) | ACCEPT(2) Cole, Wall | NOOP(4) Christey, Dik, Levy, Shostack | RECAST(3) Baker, Meunier, Ziese | REVIEWING(2) Bishop, Blake | Christey> ********************************************************** | THIS CANDIDATE HAS GENERATED A LONG THREAD. SEE THE | EDITORIAL BOARD ARCHIVES FOR DETAILS, BEGINNING AT | | http://cve.mitre.org/Board_Sponsors/archives/msg00590.html | | ********************************************************** | Ziese> | 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 | computers. | | 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 | efficiently. | | Pascal | | 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 | converter. | 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 | some more. | 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 | an exposure). | | 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. | | Wall> | 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 | Network. | 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 | http://cve.mitre.org/About_CVE/About/definition.html | Cole> Even with all of the debate i accept this one. | Christey> With respect to inclusion of design flaws in CVE, review | http://cve.mitre.org/Board_Sponsors/archives/msg00602.html | | 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 | abstraction. | 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 | discussion. | 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. | View |
| 1717 | CVE-2000-0139 | Entry | Internet Anywhere POP3 Mail Server allows local users to cause a denial of service via a malformed RETR command. | View | |||
| 1718 | CVE-2000-0140 | Entry | Internet Anywhere POP3 Mail Server allows remote attackers to cause a denial of service via a large number of connections. | View | |||
| 1719 | CVE-2000-0141 | Entry | Infopop Ultimate Bulletin Board (UBB) allows remote attackers to execute commands via shell metacharacters in the topic hidden field. | View | |||
| 1720 | CVE-2000-0142 | Candidate | The authentication protocol in Timbuktu Pro 2.0b650 allows remote attackers to cause a denial of service via connections to port 407 and 1417. | Proposed (20000216) | ACCEPT(4) Bishop, Blake, Cole, LeBlanc | MODIFY(2) Frech, Levy | NOOP(2) Baker, Christey | Frech> XF:timbuktu-auth-dos | Levy> BID 984 | Christey> BUGTRAQ:20000412 Timbuktu DoS repaired by Netopia | http://www.securityfocus.com/archive/1/54850 | BID:984 | View |
Page 344 of 20943, showing 5 records out of 104715 total, starting on record 1716, ending on 1720
