COMMAND
	    kernel
SYSTEMS AFFECTED
	    BSDish
PROBLEM
	    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.