<<< Date Index >>>     <<< Thread Index >>>

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