Date: Thu, 14 Jul 2005 15:28:31 -0300
From: Fernando Gont <fernando@....utn.edu.ar>
To: Vic Vandal <vvandal@...l.com>,full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com
Cc: Markus Friedl <markus@...nbsd.org>, Theo de Raadt <deraadt@....openbsd.org>
Subject: Re: 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@...t.com.ar || fgont@....org





_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists