COMMAND
kernel
SYSTEMS AFFECTED
Sun, HpUX 11.00
PROBLEM
Ofir Arkin and Alfredo Andrés Omella found following. It appears
that only some of the operating systems would answer an ICMP
Address Mask Request. Those operating systems include: ULTRIX
OpenVMS, Windows 95/98/98 SE/ME, NT below SP 4, and SUN Solaris
machines. How can we distinguish between those who answer the
request?
This is a regular Address Mask Request sent by SING
http://sourceforge.net/projects/sing
written by Alfredo Andrés Omella, to a SUN Solaris 2.7 machine:
[root@aik icmp]# ./sing -mask IP_Address
SINGing to IP_Address (IP_Address): 12 data bytes
12 bytes from IP_Address: icmp_seq=0 ttl=236 mask=255.255.255.0
12 bytes from IP_Address: icmp_seq=1 ttl=236 mask=255.255.255.0
12 bytes from IP_Address: icmp_seq=2 ttl=236 mask=255.255.255.0
12 bytes from IP_Address: icmp_seq=3 ttl=236 mask=255.255.255.0
12 bytes from IP_Address: icmp_seq=4 ttl=236 mask=255.255.255.0
--- IP_Address sing statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
All operating systems that would answer with ICMP Address Mask
Reply would reply with the Address Mask of the network they reside
on. What would happen if we would introduce a little twist? Lets
say we would send those queries fragmented?
In the next example, we have sent ICMP Address Mask Request to the
same SUN Solaris 2.7 box, this time fragmented to pieces of 8
bytes of IP data. As we can see the answer we got was unusual
(the -c 2 option used with SING enables it to send two ICMP
Address Mask request datagrams only):
[root@aik icmp]# ./sing -mask -c 2 -F 8 IP_Address
SINGing to IP_Address (IP_Address): 12 data bytes
12 bytes from IP_Address: icmp_seq=0 ttl=241 mask=0.0.0.0
12 bytes from IP_Address: icmp_seq=1 ttl=241 mask=0.0.0.0
--- IP_Address sing statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
[root@aik icmp]#
The tcpdump trace:
20:02:48.441174 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
icmp: address mask request (frag 13170:8@0+)
4500 001c 3372 2000 ff01 50ab 8b5c d015
xxxx xxxx 1100 aee3 401c 0000
20:02:48.442858 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
(frag 13170:4@8)
4500 0018 3372 0001 ff01 70ae 8b5c d015
xxxx xxxx 0000 0000
20:02:49.111427 ppp0 < Host_Address > slip139-92-208-21.tel.il.prserv.net:
icmp: address mask is 0x00000000 (DF)
4500 0020 3618 4000 f101 3c01 xxxx xxxx
8b5c d015 1200 ade3 401c 0000 0000 0000
20:02:49.441492 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
icmp: address mask request (frag 13170:8@0+)
4500 001c 3372 2000 ff01 50ab 8b5c d015
xxxx xxxx 1100 ade3 401c 0100
20:02:49.442951 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
(frag 13170:4@8)
4500 0018 3372 0001 ff01 70ae 8b5c d015
xxxx xxxx 0000 0000
20:02:50.011433 ppp0 < Host_Address > slip139-92-208-21.tel.il.prserv.net:
icmp: address mask is 0x00000000 (DF)
4500 0020 3619 4000 f101 3c00 xxxx xxxx
8b5c d015 1200 ace3 401c 0100 0000 0000
The same SUN Solaris box now replies with a 0.0.0.0 as the Address
Mask for the Network it resides on. What would happen with the
other operating systems? They all would respond with the
same/real Address Mask Reply.
Here we got a distinction between SUN Solaris machines and the
other operating systems that would answer those queries. When
this has been tested with this method authors encountered some
problems replicating the results with different ISPs. As it seems
from analyzing the information they got, certain ISPs would block
fragmented ICMP datagrams. This behavior would not enable this
method to succeed.
Operating Systems tested:
LINUX Kernel 2.4t2; LINUX Kernel 2.2.14; FreeBSD 4.0, 3.4;
OpenBSD 2.7 & 2.6; Solaris 2.5.1, 2.6, 2.7 & 2.8; HP-UX 10.20;
AIX 4.1; ULTRIX; Microsoft Windows 95 / 98 / 98SE / ME / NT 4
SP3, SP4, SP6a WRST & SERVER / 2000 Professional & Server.
According to Peter J. Holzer, HP-UX 11.00 has same behaviour.
Amusing, but not as strange as it seems because both share their
TCP/IP STREAMS lineage with the same third party crowd (Mentat).
SOLUTION
Block fragmented ICMP datagrams. One reason why good solaris
admins do things like:
ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0