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.