Precedence field value in ICMP Error Messages with LINUX Kernels 2.2.x & 2.4

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

This is a corrected post for the post I have sent on 14.10.2000
Titled "TOS Field value in ICMP Error Messages with LINUX
Kernels 2.2.x & 2.4".
---------------------------------------------------------------

Each IP Datagram has an 8-bit field called the “TOS Byte”,
which represents the IP support for prioritization and
Type-of-Service handling.

The “TOS Byte” consists of three fields.

The “Precedence field”, which is 3-bit long, is intended to
prioritize the IP Datagram. It has eight levels of prioritization.


Higher priority traffic should be sent before lower priority
traffic.

The second field, 4 bits long, is the “Type-of-Service” field.
It is intended to describe how the network should make tradeoffs
between throughput, delay, reliability, and cost in routing an
IP Datagram.

The last field, the “MBZ” (most be zero), is unused and most be
zero. Routers and hosts ignore this last field. This field is 1
bit long.


RFC 1122 Requirements for Internet Hosts -- Communication
Layers, states:
“The Precedence field is intended for Department of Defense
applications of the Internet protocols.  The use of non-zero
values in this field is outside the scope of this document and
the IP standard specification.  Vendors should consult the
Defense Communication Agency (DCA) for guidance on the IP
Precedence field and its implications for other protocol layers.
However, vendors should note that the use of precedence will
most likely require that its value be passed between protocol
layers in just the same way as the TOS field is passed”.

Other precedence information is available with RFC 1812
Requirements for IP Version 4 Routers:
“4.3.2.5 TOS and Precedence
…

ICMP Source Quench error messages, if sent at all, MUST have
their IP Precedence field set to the same value as the IP
Precedence field in the packet that provoked the sending of
the ICMP Source Quench message.  All other ICMP error messages
(Destination Unreachable, Redirect, Time Exceeded, and
Parameter Problem) SHOULD have their precedence value set to 6
(INTERNETWORK CONTROL) or 7 (NETWORK CONTROL).  The IP
Precedence value for these error messages MAY be settable”.

With the operating systems I have checked, nearly all of them
used the value of 0x00 for the Precedence field (bits).

All but LINUX

Fyodor had outlined in his paper “Remote OS Identification by
TCP/IP Fingerprinting”   the fact that LINUX is using the value
of 0xc0 (an unused precedence value) as its TOS byte value with
ICMP Port Unreachable error messages.

In the next example we have sent one UDP packet destined to port
50 (which is closed on the destination machine) from one LINUX
machine to another, both running Redhat LINUX 6.1:


[root@stan /root]# hping2 -2 192.168.5.5 -p 50 -c 1
default routing not present
HPING 192.168.5.5 (eth0 192.168.5.5): udp mode set, 28 headers +
0 data bytes
ICMP Port Unreachable from 192.168.5.5  (kenny.sys-security.com)

--- 192.168.5.5 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms


Kernel filter, protocol ALL, raw packet socket
Decoding Ethernet on interface eth0
03/12-12:54:47.274096 192.168.5.1:2420 -> 192.168.5.5:50
UDP TTL:64 TOS:0x0 ID:57254
Len: 8

03/12-12:54:47.274360 192.168.5.5 -> 192.168.5.1
ICMP TTL:255 TOS:0xC0 ID:0
DESTINATION UNREACHABLE: PORT UNREACHABLE
00 00 00 00 45 00 00 1C DF A6 00 00 40 11 0F D4  ....E.......@...
C0 A8 05 01 C0 A8 05 05 09 74 00 32 00 08 6A E1  .........t.2..j.


This abnormality with LINUX is not only limited to ICMP Destination
Unreachable Port Unreachable error messages.

Lets examine the next trace:


00:30:08.339498 < x.x.x.x > y.y.y.y: ip-proto-72 0 (ttl 49, id
38624)
                         4500 0014 96e0 0000 3148 f4bf xxxx xxxx
                         yyyy yyyy
00:30:08.339559 > y.y.y.y > x.x.x.x: icmp: y.y.y.y protocol 72
unreachable Offending pkt: x.x.x.x > y.y.y.y: ip-proto-72 0
(ttl 49, id 38624) [tos 0xc0]  (ttl 255, id 37)
                         45c0 0044 0025 0000 ff01 bcd1 yyyy yyyy
                         xxxx xxxx 0302 fb1a 0000 0000 4500 0014
                         96e0 0000 3148 f4bf xxxx xxxx yyyy yyyy
                         0050 d909 621b 96f7 0000 0000 5004 0000
                         df71 0000

The ICMP error message produced by a LINUX machine based on Kernel
2.2.14, is Destination Unreachable Protocol Unreachable (Type 3
Code 2). As it can be seen the TOS Byte value that was used is
again 0xc0. Which is an unused Precedence bits value.

LINUX embraced the behavior RFC 1812 suggested and sends all his
ICMP error messages with the Precedence field value sent to 0xc0
(value of 6).

Just to remind the reader – LINUX is not a router.

---------------------------------------------------------------
I would like the thank Robert Bihlmeyer [robbe () ORCUS PRIV AT]
for correcting my mistake with the previous post.


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).