Date: Tue, 28 May 2002 22:05:09 +0100 From: Ofir Arkin To: bugtraq@securityfocus.com Subject: Nuisance with small (< 46bytes) IP packets and tcpdump @stake Inc. www.atstake.com Advisory Name: Nuisance with small (< 46bytes) IP packets and tcpdump Release Date: 05/28/2002 Application: tcpdump (http://www.tcpdump.org) Platform: compiled OSs Severity: Nuisance Author: Ofir Arkin (ofir@atstake.com) Vendor Status: Notified Reference: www.atstake.com/research/advisories/2002/ Summary: With IP packets smaller than 46 data bytes the tcpdump program will display the Ethernet trailer information when asked to strip-off any link-layer information (-x option) when it is displaying captured data. The trailer information will look like a valid IP packet data. Detailed Description: While using tcpdump versions 3.7.1 and 3.6 I believe I have found a bug with the representation of the Ethernet Trailer information. The minimum size an Ethernet frame can have is 60 data bytes. This gives the IP portion of the frame a minimum size of 46 data bytes. The sending Host's underlying operating system needs to ensure that if the IP portion of a frame will be smaller than 46 data bytes; padded data will be added to meet minimum requirements. The content of the padded data is undetermined by the IEEE 802.3 standard. When an IEEE 802.3 Ethernet frame is received the length field is used to determine the length of the valid data within the frame, and therefore the padded data will be ignored. If the frame we receive is an Ethernet DEC-Intel-Xerox (DIX) compatible frame, there is no length field. Instead this field is defined to hold a "type" for the type of the high-level protocol which is being carried by the Ethernet frame. For example, 0x0800 represents IP. In this case the IP packet length field value should be used in identifying valid IP packet data (the padded data is added at the physical layer). The tcpdump case: With tcpdump you can strip the link-layer information using the -x option. But, there is a little nasty bug that will still keep the Trailer information visible as a legitimate part of the IP packet's data. With the next example I have sent an ICMP Timestamp request from a 2.4.18 Kernel-based Linux machine to a Sun Solaris 2.8 destination machine. The usual size of an ICMP Timestamp reply is 40 data bytes. Let us examine the next tcpdump trace, which was product with the options -vvxn: 13:16:23.010811 x.x.x.x > y.y.y.y: icmp: time stamp query id 40973 seq 0 (ttl 255, id 13170, len 40) 4500 0028 3372 0000 ff01 70ed xxxx xxxx yyyy yyyy 0d00 226f a00d 0000 02a2 2de1 0000 0000 0000 0000 0000 0000 0000 13:16:23.011395 y.y.y.y > x.x.x.x: icmp: time stamp reply id 40973 seq 0 : org 0x2a22de1 recv 0x2a6c8c9 xmit 0x2a6c8c9 (DF) (ttl 255, id 42448, len 40) 4500 0028 a5d0 4000 ff01 be8e yyyy yyyy xxxx xxxx 0e00 8a8f a00d 0000 02a2 2de1 02a6 c8c9 02a6 c8c9 5555 5555 5555 As you can see there are 6 bytes more than it is needed to be with the ICMP Timestamp Reply (yes, also with the Timestamp Request). The extra 6 data bytes are the padded data bytes inserted by Sun Solaris 2.8 to meet the Ethernet requirements for minimum Frame length. The total packet size is 40 bytes, as presented by the IP Total Length field value (0028 hex is 40 decimal). But, with tcpdump the extra 6 data bytes (5555 5555 5555) are displayed as they are part of the IP packet. Vendor Response: Tcpdump is an open source project. A copy of this bug report was submitted to http://www.tcpdump.org. The first response was that: "tcpdump captures the packets as they appear on the wire; while -x does strip off the link-layer header it does not strip off the trailer, so you are seeing the expected behavior". I have argued that there is no option to specifically strip-off the Ethernet Trailer information. Where in my opinion it should be stripped-off in the first place by the -x option. And the second reply was: "It's displayed because it's part of the packet that was captured. There is no option to strip it off. This should probably be more clear in the documentation". Interesting - I still think this is not a part of the IP packet, it is part of the Frame... Why I bother with this? Because a lot of people, knowledgeable or not, use tcpdump, and rely on tcpdump. In my opinion this should be an easy fix in the software rather than an explanation in the documentation. Temporary Solution: I use snort (http://www.snort.org) which does not suffer from the same mistake. You can also use ethereal (http://www.ethereal.com) which at least identify the Trailer information when it displays the packet's data. Last Interesting Note: As I stated with the description, the content of the padded data is undetermined by the IEEE 802.3 standard. The data placed with the padded bytes is implementation dependent. Just think about it. Credits: Josh Anderson Hope you have found this information useful, Ofir Arkin [ofir@atstake.com] Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com