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