TOS bits (=field) Echoing with ICMP Error Messages

["Ofir Arkin" <ofir () itcon-ltd com>]

RFC 1394 specify that an ICMP error message is always sent
with the default TOS field value of 0000 (TOS field=TOS
bits in the TOS Byte).

When an offending packet with a TOS field value of 0000 is
eliciting an ICMP error message from an offended host, the
TOS field value with all the operating systems I have checked
will be set to 0000.

If we will pay attention to the TOS Byte we will see that LINUX
and several routers will use the value of 0xc0 for the precedence
field.

What will happen if the TOS field with the offending packet will
be set to a value different than the default (0000)?

We will have several operating systems that will echo the TOS
field back with the ICMP error message.

Our first example is with an AIX 4.3 machine, where a UDP datagram
is sent with a TOS field value of 0x10 hex:

12:33:17.319275 ppp0 > x.x.x.x.2160 > y.y.y.y.0: udp 0 [tos 0x10]
(ttl 64, id 47349)
                         4510 001c b8f5 0000 4011 9bea xxxx xxxx
                         yyyy yyyy 0870 0000 0008 d18c
12:33:17.614823 ppp0 < y.y.y.y > x.x.x.x: icmp: y.y.y.y udp
port 0 unreachable Offending pkt: x.x.x.x.2160 > y.y.y.y.0: udp 0
[tos 0x10]  (ttl 49, id 47349, bad cksum aaea!) [tos 0x10]  (ttl
241, id 17965)
                         4510 0038 462d 0000 f101 5da6 yyyy yyyy
                         xxxx xxxx 0303 f470 0000 0000 4510 0030
                         b8f5 0000 3111 aaea xxxx xxxx yyyy yyyy
                         0870 0000 0008 0000

As it can be seen from the trace, the TOS field value was echoed
back by the AIX machine. This was tested against AIX 4.1, 4.2.1,
4.3, 4.3 fix pack2.


The next example is with DGUX 5.6:

12:58:57.663517 ppp0 > x.x.x.x.1074 > y.y.y.y.11: udp 0 [tos 0x8]
(ttl 64, id 47314)
                         4508 001c b8d2 0000 4011 a037 xxxx xxxx
                         yyyy yyyy 0432 000b 0008 d9e1
12:58:57.984820 ppp0 < 134.210.1.200 > x.x.x.x.: icmp: y.y.y.y.200
udp port 11 unreachable Offending pkt: x.x.x.x.1074 > y.y.y.y.11:
udp 0 [tos 0x8]  (ttl 52, id 47314) [tos 0x8]  (ttl 52, id 16984)

                         4508 0038 4258 0000 3401 22a6 yyyy yyyy
                         d508 c41c 0303 f8b7 0000 0000 4508 001c
                         b8d2 0000 3411 ac37 xxxx xxxx yyyy yyyy
                         0432 000b 0008 0000

How can we differentiate between DGUX and AIX? If we will pay
attention to the echoing integrity. AIX 4.x sets the IP total
length field value, with the echoed offending IP Header, to a value
20 bytes higher than the original. DGUX quote this field value
correctly.

The last operating system, which I have found echoing the TOS
field value with its ICMP error messages, is LINUX operating
systems based on Kernel 2.2.x & 2.4 (the versions of the Kernel
that I have tested):


00:50:43.759906 ppp0 > x.x.x.x.1952 > y.y.y.y.0: udp 0 [tos 0x10]
(ttl 64, id 15952)
                         4510 001c 3e50 0000 4011 e6b2 xxxx xxxx
                         yyyy yyyy 07a0 0000 0008 a27f

00:50:44.154556 ppp0 < y.y.y.y > x.x.x.x: icmp: y.y.y.y.211 udp
port 0 unreachable Offending pkt: x.x.x.x.1952 > y.y.y.y.0: udp 0
[tos 0x10]  (ttl 47, id 15952) [tos 0xd0]  (ttl 238, id 54662)

                         45d0 0038 d586 0000 ee01 a0af yyyy yyyy
                         xxxx xxxx 0303 52d5 0000 0000 4510 001c
                         3e50 0000 2f11 f7b2 xxxx xxxx yyyy yyyy
                         07a0 0000 0008 a27f

Another unique pattern with LINUX is setting the Precedence field
value to 0xc0 with ICMP error messages. This helps us to
differentiate LINUX from the other operating systems that echo
the TOS field value.

While LINUX embraced RFC 1812 instructions for routers regarding
the TOS and Precedence fields, the other operating systems that
echo the TOS field value don’t seem to have a good excuse for
doing so.

This info was sent to bugtraq as well.


Ofir Arkin  [ofir () itcon-ltd com]
Senior Security Analyst
Chief of Grey Hats
ITcon, Israel.
http://www.itcon-ltd.com

Personal Web page: http://www.sys-security.com

"Opinions expressed do not necessarily
represent the views of my employer."



--------------------------------------------------
For help using this (nmap-hackers) mailing list, send a blank email to 
nmap-hackers-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).