Vulnerability

    kernel

Affected

    Sun, HpUX 11.00

Description

    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