lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Pine.GSO.4.58.0507121215520.14166@well.com> Date: Tue Jul 12 22:43:03 2005 From: vvandal at well.com (Vic Vandal) Subject: ICMP Security Vulnerabilities - NEW (cough) I know this is now even older news than it was when the recent flurry of discussion started last week, but I'm just getting around to sharing a bit of additional information on the subject. Regarding those three (3) "vulnerabilities" discussed by Fernando (can't recall his last name, no offense meant), followed by a link to and discussion of here, I respectfully submit the following: 1) Regarding ONLY the "source quench" discussion there, that is absolutely "nothing new". I've had a paper/guide mentioning it specifically since 1994, that I've shared with various entities I've worked for since that time. That same paper was posted to some BSD-related mailing list back in 1997 or 1998 (by a friend of mine who I had shared it with), but I can't recall the list/site name. I've also provided it to various friends in the InfoSec industry (as recommended ICMP filtering guidance) sporadically through the years. Yes I know Fernando's paper elaborated a bit on potential fixes, but regarding ONLY the "source quench" item again it is not "new" and has been discussed in various circles in the past. 2) I also personally launched a source-quench DoS "over the shoulder" of a friend who was competing in CTF at DefCon MANY years ago, which "may" have been the first DoS in those games (it certainly pre-dated the massive DoS storms later years saw). 3) I didn't "discover" the "source quench" nor any other ICMP "vulnerability", but took the work of others to provide some guidance on firewall filtering. I wish I could give exact credit where credit is due, but don't have that kind of free time to dig through my boxes upon boxes of printed and digital resources. Also the pointers in my mind to such details (stored a decade or more ago) have been broken somewhere in time passed. I will acknowledge that the first "widely published" discussion on the exact topic of ICMP filtering was "probably" in the 1995 release of "Building Internet Firewalls" (by Chapman and Zwicky). I had the book in my desk back then, but left it behind when I left the organization that paid for it. IF I still had it, I'd gladly quote it directly to verify the exact verbiage/discussion of the topic therein. 4) For future reference, I'll share the ICMP filtering guidance here (mentioned in item #1 above). Perhaps it will help someone secure their environment, and possibly discount some "newly" discovered vulnerabilities as "old news" in the future (which I suspect some jackasses will start posting a few of these as their own "discoveries" shortly). 5) Noting #4 above, this information may be re-published/distributed ONLY with the ENTIRE contents of this e-mail/posting (including these numbered statements/disclaimers). 6) No I haven't notified "CERT", "Micro$oft", or any other vendor/organization. This is "old news" after all, and I assume "being able to read" is a prerequisite for becoming employed at most places dealing with such things. And if Cisco or anyone else wants to claim some kind of patent protection for such info, I promise I will dig up sources that show non-"any vendor mentioned in the recent post/article" releases of these details as far back as 1994-95. You can bet the house on that. Nuff said! Here's the list (cut-and-pasted from HTML, so please excuse the lame formatting): "Un-Official Guide to Secure ICMP Packet Filtering" (applicable to firewalls, routers, and/or other packet-filtering devices) Produced by: Stuart Thomas and Vic Vandal Original Publish Date: 1994 Last Content Revision: 1995 Format Revisions: various dates Echo and Echo Reply Messages - ICMP Code Type 8 Discussion: The echo message (also called echo request) is used to check if a host is up or down. When a host receives the request, it sends back an echo reply message. These messages are usually generated by the ping command, but may also be generated by a network management device that is polling the nodes of a network. Security Issues: Echo requests can be used by an outsider to map your network. Firewall Filtering: Allow the outbound echo request and inbound echo reply. Deny the inbound echo request and outbound echo reply Destination Unreachable Message - ICMP Code Type 3 Description: These messages are generated by hosts or intermediate routers, in order to notify the initiator that a session cannot be established. Security Issues: An attacker can force nodes of your network to generate these packets, in order to obtain knowledge of your network. Firewall Filtering: Allow the inbound message (for troubleshooting purposes). Deny the outbound message. Source Quench Message - ICMP Code Type 4 Description: This message is generated by a host or a router when it wants the sender to slow down the rate it is sending packets. The IP stack passes this packet to the upper layers, and they are responsible for slowing the rate down. Security Issues: This message could be used by an attacker (probably combined with IP spoofing) in order to make a very effective denial of service attack. Unfortunately it is more often a legitimate message. If filtered, problems may arise due to lost packets. Firewall Filtering: Allow it to be sent and received, but log the received messages for later analysis Redirect Message - ICMP Code Type 5 Description: This message is generated by a router when it receives a packet from a host, and forwards the packet to another router that is on the same network as the host it received the packet from (not the original sender, the "last hop" sender). Redirect messages are not supposed to cross routers. The packet is only sent when the sender and both routers are on the same physical network. Security Issues: Redirect has a very specific, legitimate use (described above). However it can be abused by a cracker to subvert the routing table, and thereby allow IP address spoofing. Firewall Filtering: Allow this to be sent, but log it. Deny receipt of this packet. (Notify the owners of machines to which you sent redirects, so that they can correct their routing tables.) Time Exceeded Message - ICMP Code Type 11 Description: Time to live exceeded is generated by a router when it has to forward a packet with a time to live (TTL) value of zero. Fragment reassembly time exceeded is generated by a host when it does not receive all the fragments needed to reassemble a packet. Security Issues: An attacker can use traceroute to find out which hosts are the routers in your network. Firewall Filtering: Allow this for inbound packets, so your hosts can perform error recovery. Also allow all fragment reassembly time exceeded messages for outbound packets, but not the TTL exceeded messages. Parameter Problem Message - ICMP Code Type 12 Description: This message is generated when a host processing a packet finds a problem in the header parameters that forces the packet to be discarded. Security Issues: An attacker will gain no information with this packet. Firewall Filtering: Allow it inbound and outbound, in order to report problems. Time Stamp / Time Stamp Reply Message - ICMP Code Type 13 Description: The time stamp message is used to identify the time (in milliseconds) since midnight. It receives a time stamp reply message as a response. Security Issues: This protocol may be used by an attacker as a mapping tool (an alternative to ping). Firewall Filtering: Deny it inbound and outbound. Information Request Message - ICMP Code Type 15 Description: This message is used by a host booted across the network, to "learn" in which IP network it is located. These messages are made obsolete by new protocols, such as RARP, BOOTP and DHCP. Also RFC-1122 indicates that hosts should not implement this protocol. Security Issues: This message is for local networks only, so it does not need to cross a router. No Firewall should generate these requests, because it its IP interfaces are already identified/configured. Firewall Filtering: Deny it inbound and outbound. Address Mask Request and Address Mask Reply - ICMP Code Type 17 Description: The address mask request message is sent when a node wants to know the address mask of an interface. Security Issues: This message can be used by attackers to learn the topology of your network. There are also cases in which a TCP/IP stack takes "inappropriate" actions in response to an unsolicited address mask reply. Firewall Filtering: Deny it inbound and outbound. Router Advertisement and Router Solicitation Message - ICMP Code Type 9 Description: These messages are used by hosts in order to dynamically discover routers in a network. It is specified in RFC-1256, and the current status of the protocol is "elective". Security Issues: These messages are for local networks only. Firewall Filtering: Deny the messages inbound and outbound. Domain Name Request and Domain Name Reply Messages - ICMP Code Type 37 Description: These messages are used by hosts to learn the domain associated with an address. Security Issues: The ICMP implementation of this is not currently used. Firewall Filtering: Deny it inbound and outbound. Traceroute Message - ICMP Code Type 30 Description: This message is used in order to implement traceroute in a more efficient way. It is specified in RFC-1393. The current status of the protocol is "experimental". Security Issues: This could be used by an attacker to map your internal network. Firewall Filtering: It can be allowed inbound, but deny it outbound. ALL other ICMP packets (everything NOT covered above) Firewall Filtering: Block all ICMP packets inbound and outbound. THE END!!! Peace, Vic NOTE: See the #5 comment above regarding further sharing of all content included in this message as stated in this message.
Powered by blists - more mailing lists