Re: [Full-disclosure] ICMP Security Vulnerabilities - NEW (cough)
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@xxxxxxxxxxx || fgont@xxxxxxx