CVE List
| Id | CVE No. | Status | Description | Phase | Votes | Comments | Actions |
|---|---|---|---|---|---|---|---|
| 520 | CVE-1999-0523 | Candidate | ICMP echo (ping) is allowed from arbitrary hosts. | Proposed (19990726) | MODIFY(1) Meunier | NOOP(1) Baker | REJECT(2) Frech, Northcutt | Northcutt> (Though I sympathize with this one :) | CHANGE> [Frech changed vote from REVIEWING to REJECT] | Frech> Ping is a utility that can be run on demand; ICMP echo is a | message | type. As currently worded, this candidate seems as if an arbitrary | host | is vulnerable because it is capable of running an arbitrary program | or | function (in this case, ping/ICMP echo). There are many | programs/functions that | "shouldn"t" be on a computer, from a security admin"s perspective. | Even if this | were a vulnerability, it would be impacted by CD-HIGHCARD. | Meunier> Every ICMP message type presents a vulnerability or an | exposure, if access is not controlled. By that I mean not only those | in RFC 792, but also those in RFC 1256, 950, and more. I think that | the description should be changed to "ICMP messages are acted upon | without any access control". ICMP is an error and debugging protocol. | We complain about vendors leaving testing backdoors in their programs. | ICMP is the equivalent for TCP/IP. ICMP should be in the dog house, | unless you are trying to troubleshoot something. MTU discovery is | just a performance tweak -- it"s not necessary. I don"t know of any | ICMP message type that is necessary if the network is functional. | Limited logging of ICMP messages could be useful, but acting upon them | and allowing the modification of routing tables, the behavior of the | TCP/IP stack, etc... without any form of authentication is just crazy. | View |
| 522 | CVE-1999-0525 | Candidate | IP traceroute is allowed from arbitrary hosts. | Proposed (19990726) | MODIFY(1) Frech | NOOP(1) Baker | REJECT(1) Northcutt | Frech> XF:traceroute | View |
| 525 | CVE-1999-0528 | Candidate | A router or firewall forwards external packets that claim to come from inside the network that the router/firewall is in front of. | Proposed (19990726) | ACCEPT(3) Baker, Meunier, Northcutt | MODIFY(1) Frech | Frech> possibly XF:nisd-dns-fwd-check | CHANGE> [Frech changed vote from REVIEWING to MODIFY] | Frech> XF:firewall-external-packet-forwarding(8372) | View |
| 526 | CVE-1999-0529 | Candidate | A router or firewall forwards packets that claim to come from IANA reserved or private addresses, e.g. 10.x.x.x, 127.x.x.x, 217.x.x.x, etc. | Proposed (19990726) | ACCEPT(1) Frech | MODIFY(2) Baker, Meunier | REJECT(1) Northcutt | Northcutt> I have seen ISPs "assign" private addresses within their domain | Meunier> A border router or firewall forwards packets that claim to come from IANA | reserved or private addresses, e.g. 10.x.x.x, 127.x.x.x, 217.x.x.x, | etc, outside of their area of validity. | CHANGE> [Frech changed vote from REVIEWING to ACCEPT] | Baker> I think the description should be modified to say they accept this type of traffic from an interface not residing on private/reserved network. | View |
| 529 | CVE-1999-0532 | Candidate | A DNS server allows zone transfers. | Proposed (19990726) | MODIFY(1) Frech | NOOP(1) Baker | REJECT(1) Northcutt | Northcutt> (With split DNS implementations this is quite appropriate) | Frech> XF:dns-zonexfer | View |
Page 20529 of 20943, showing 5 records out of 104715 total, starting on record 102641, ending on 102645
