Back to list
Re: [Full-disclosure] ICMP Security Vulnerabilities - NEW (cough)
Jul 14 2005 06:28PM
Fernando Gont (fernando frh utn edu ar)
At 06:42 p.m. 12/07/2005, Vic Vandal wrote:
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
>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.
>Echo requests can be used by an outsider to map your network.
>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
>These messages are generated by hosts or intermediate routers,
>in order to notify the initiator that a session cannot be
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
>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.
>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.
>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.
>Time Exceeded Message - ICMP Code Type 11
>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.
>An attacker can use traceroute to find out which hosts are the
>routers in your network.
>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
e-mail: fernando (at) gont.com (dot) ar [email concealed] || fgont (at) acm (dot) org [email concealed]
[ reply ]
Copyright 2010, SecurityFocus