CVE List
| Id | CVE No. | Status | Description | Phase | Votes | Comments | Actions |
|---|---|---|---|---|---|---|---|
| 3144 | CVE-2001-0323 | Candidate | The ICMP path MTU (PMTU) discovery feature in various UNIX systems allows remote attackers to cause a denial of service by spoofing "ICMP Fragmentation needed but Don"t Fragment (DF) set" packets between two target hosts, which could cause one host to lower its MTU when transmitting to the other host. | Modified (20131008) | ACCEPT(2) Frech, Meunier | NOOP(4) Christey, Cole, Wall, Ziese | REVIEWING(1) Bishop | Christey> (prompted from Pascal Meunier) should this be treated | as a general design issue with ICMP? Or is it a specific | implementation flaw that only affects Reliant? | Meunier> It seems obvious that if one sets the MTU to just one byte | above the size of a IP header (let"s say 21 bytes), data transmission | is not going to go anywhere fast, as the overhead will be 20 times the | payload... As I said for another candidate, ICMP messages should not | be acted upon without access control. I"m not sure that references to | UNIX should be kept. It seems that this should work with any OS. It | would be nasty if some OSes accepted an MTU of 20, as you could not | transmit any IP data. | View |
| 3019 | CVE-2001-0198 | Candidate | Buffer overflow in QuickTime Player plugin 4.1.2 (Japanese) allows remote attackers to execute arbitrary commands via a long HREF parameter in an EMBED tag. | Modified (20130403) | ACCEPT(1) Frech | NOOP(3) Christey, Lawler, Ziese | Christey> Fix typo: "paramater" | Christey> fix typo: "paramatar" | View |
| 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 |
| 3674 | CVE-2001-0868 | Candidate | Red Hat Stronghold 2.3 to 3.0 allows remote attackers to retrieve system information via an HTTP GET request to (1) stronghold-info or (2) stronghold-status. | Modified (20120911) | NOOP(3) Armstrong, Cole, Foat | REVIEWING(1) Wall | View | |
| 5229 | CVE-2002-0839 | Candidate | The shared memory scoreboard in the HTTP daemon for Apache 1.3.x before 1.3.27 allows any user running as the Apache UID to send a SIGUSR1 signal to any process as root, resulting in a denial of service (process kill) or possibly other behaviors that would not normally be allowed, by modifying the parent[].pid and parent[].last_rtime segments in the scoreboard. | Modified (20110830) | ACCEPT(3) Armstrong, Cole, Green | MODIFY(1) Cox | NOOP(1) Christey | Christey> CONFIRM:http://www.info.apple.com/usen/security/security_updates.html | Cox> Addref: RHSA-2002:251 | Addref: RHSA-2002:248 | Addref: RHSA-2002:244 | Addref: RHSA-2002:243 | Addref: RHSA-2002:222 | Change Apache Week ref to: http://www.apacheweek.com/issues/02-10-04#security | Christey> SGI:20021105-02-I | URL:ftp://patches.sgi.com/support/free/security/advisories/20021105-02-I | View |
Page 429 of 20943, showing 5 records out of 104715 total, starting on record 2141, ending on 2145
