Vulnerability

    kernel

Affected

    BSDish

Description

    Ofir  Arkin  found  following.   When  sending  back an ICMP error
    message,  some  stack  implementations  may  alter  the  offending
    packet's IP header  and the underlying  protocol's data, which  is
    echoed back with the ICMP error message.

    If a malicious computer attacker examines the types of alternation
    that have been  made to the  offending packet's IP  header and the
    underlying  protocol's  data,  he  may  be  able  to  make certain
    assumptions about the target operating system.

    The only  two field  values we  expect to  be changed  are the  IP
    time-to-live field value and the  IP header checksum.  The  IP TTL
    field value changes  because the field  is decreased by  one, each
    time the IP Header is being processed.  The IP header checksum  is
    recalculated each time the IP TTL field value is decreased.

    The fields that are usually being used in order to take  advantage
    of  this  echoing  integrity  fingerprinting  method are: IP Total
    Length,  IP  ID,  IP  Header  Checksum,  and if using UDP, the UDP
    header checksum.

    During research on X (to  be published at the Black  Hat Briefings
    2001 July  11-12) Ofir  has found  a new  field value  that can be
    used with this method.  The next example is with NetBSD 1.3:

        21:46:07.489298 eth0 > 172.18.2.201.1144 > 172.18.2.20.re-mail-ck: udp
        80 (DF) [tos 0x11]  (ttl 64, id 44586)
                                 4511 006c ae2a 4000 4011 2f44 ac12 02c9
                                 ac12 0214 0478 0032 0058 cfc4 5858 5858
                                 5858 5858 5858 5858 5858 5858 5858 5858
                                 5858 5858 5858 5858 5858 5858 5858 5858
                                 5858 5858 5858 5858 5858 5858 5858 5858
                                 5858 5858 5858 5858 5858 5858 5858 5858
                                 5858 5858 5858 5858 5858 5858
        
        21:46:07.489298 eth0 < 172.18.2.20 > 172.18.2.201: icmp: 172.18.2.20 udp
        port re-mail-ck unreachable Offending pkt: 172.18.2.201 > 172.18.2.20:
        (frag 10926:88@512) [tos 0x11]  (ttl 64, bad cksum 0!) (DF) (ttl 255, id
        56)
                                 4500 0038 0038 4000 ff01 1e8b ac12 0214
                                 ac12 02c9 0303 ea7b 0000 0000 4511 006c
                                 2aae 0040 4011 0000 ac12 02c9 ac12 0214
                                 0478 0032 0058 0000

    Looking closely at the trace above, we can see that the DF bit  is
    set  with  the  offending  UDP  datagram.   Look  at the ICMP Port
    Unreachable error message at the  echoed data part, the Bit  order
    has changed  from 4000  to 0040.   This made  the offending packet
    look like a fragmented datagram that tried to access a closed  UDP
    port.

    Who  share  the  same  behavioral  pattern?   NetBSD  1.3.x branch
    (probably the 1.x-1.2 branch as  well, but we could not  test this
    on  these  platforms),  FreeBSD  2.2.x-4.1.   It might affect some
    versions of BSDI, and MaxOS X as well.

    Other operating systems and  networking devices that were  checked
    did not produce the same behavioral pattern.

Solution

    Nohing yet.