Bugtraq mailing list archives
Re: [Full-disclosure] ICMP Security Vulnerabilities - NEW (cough)
From: Fernando Gont <fernando () frh utn edu ar>
Date: Thu, 14 Jul 2005 15:28:31 -0300
At 06:42 p.m. 12/07/2005, Vic Vandal wrote: Vic,I'd like to sum-up my response, before quoting your e-mail to respond to each of your comments.
a) Discussing an issue "in various circles" is not "raising awareness". The proof of that is the large number of vulnerable implementations, as listed in NISCC's and CERT/CC's vulnerability advisories.
b) Guides and papers such as yours have broken the Internet, particulary, the PMTUD mechanism. Your guide recommend to filter ICMP "fragmentation needed and DF bit set". Thus, any intermmediate system that (unfortunately) implements your proposal will break the PMTUD mechanism, and thus any connection using it will stall (except in specific scenarios in which the PMTU is the same as the MTU of your link). I don't know if it's just that the work you read was bullshit (or too old), that you didn't read it well, or that you didn't care.
Publishing non-elaborated work such as yours make more harm than good. c) Regarding the contents of the guide itself, I'll makesome comments:c1) Even when your guide is about ICMP filtering, you never mention that of egress filtering based on the ICMP payload (read my draft on this). c2) You don't provide references. Who should I blame for your guide advising to break PMTUD? Only you? You and your references? c3) You don't provide a rationale for your proposals. Why should people trust you blindly? I hope (but unfortunately don't believe) nobody implements policies and rules they don't understand.
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.
The attack is not new. The counter-measures (having TCP ignore them, perform ICMP egress-filtering based on the ICMP payload) and the rationale for them *are*, or at least, not easily available.
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.
Some other full-disclosure has the edition of 2000, and he says (and quoted the book) that the book advises to *allow* it. In any case, one of the counter-measures proposed in my draft has to do with TCP itself, rather with firewalls. And the one that has t do with firewalls is not mentioned elsewhere.
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).
Please don't distribute your guide. Not without this e-mail, alarming the sysadmin how he will DoS himself with your recommendations.
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).
If you have this guide available at some web site, please provide a link. I'd like to include a pointer to it in my draft. All the people dealing with ICMP-blackholes will probably want to do the same.
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.
It's a requirement, and you didn't bother to read the PMTUD specification???? That's quite ironic.
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
If you assume people will implement your recommendations, then filter both: ping will be useless.
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.
Actually, it's during the connection-establishment that these messages can be useful. Have a look at http://www.gont.com.ar/drafts/tcp-soft-errors.html
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.
You miss the point. Have a look at http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html for a rationale for ignoring ICMP Source Quench messages.
Firewall Filtering: Allow it to be sent and received, but log the received messages for later analysis
So I will not only slow down your connections, but also flood your logs. That's awesome.
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.
"Time Exceeded" messages are soft errors. You don't need them for fault-recovery. They are helpful for providing a more informative error message if the connection times out. Because of the "small world" phenoma, it's really unlikely you will receive one of these for anything else than traceroute. (Unless you're intentionally using the TTL to limit how far your packets can be forwarded).
From one of the slides of my presentation at CanSecWest 2005:"I know the tendency of the human mind is to do anything rather than think, But mental labor is not thought, and those who have with labour acquired the habit of application, often find it much easier to get up a formula than to master a principle."
- James Clerk Maxwell Kindest regards, -- Fernando Gont e-mail: fernando () gont com ar || fgont () acm org
Current thread:
- Re: [Full-disclosure] ICMP Security Vulnerabilities - NEW (cough) Fernando Gont (Jul 14)