unpack error on empty IPv4 packets

[mcarpenter]

The problem packet was found in a malware exercise pcap; I have extracted that single packet (attached problem_packet.pcap.zip). The error is:

$ ./chaosreader.pl problem_packet.pcap 
Chaosreader ver 0.95.10

Opening, problem_packet.pcap

Reading file contents,
 100% (2481/2481)Invalid type '-' in unpack at ./chaosreader.pl line 1008.

This is because the packet contains a length field of 0 (uint16 in the 3rd and 4th bytes). Then the packet data length is calculated:

$ip_dlength = $ip_length - $ip_options_num - 20;

This gives an $ip_dlength of -20. Opening this packet in wireshark is instructive. It reports "Total length: 2427 (reported as 0, presumed to be because of "TCP segmentation offload (TSO))". Wireshark has a forum question on this at https://osqa-ask.wireshark.org/questions/16279. This is a configurable option in wireshark "Support packet-capture from IP TSO-enabled hardware".

The pertinent code in wireshark is in epan/dissectors/packet-ip.c:

  /* Correct for zero-length TSO packets
   * If ip_len is zero, assume TSO and use the reported length instead.  Note
   * that we need to use the frame/reported length instead of the
   * actually-available length, just in case a snaplen was used on capture. */
  if (ip_tso_supported && !iph->ip_len)
    iph->ip_len = tvb_reported_length(tvb);

tvbuff_t tvbuf is a "testy, virtual(-izable) buffer", see epan/tvbuff.h, and seems essentially to be the frame data. Packet length 2427 (as reported by wireshark above as the packet length) is the length of $ether_data in chaosreader.pl. So I think this is an equivalent fix:

@@ -1004,6 +1004,9 @@
 		}
 
 		### Strip off Ethernet trailers
+		if ($ip_length == 0) {
+			$ip_length = length($ether_data);
+		}
 		$ip_dlength = $ip_length - $ip_options_num - 20;
 		($ip_data,$trailers) = unpack("a${ip_dlength}a*",$ip_data);

At least, this appears to dissect my sample bad packet okay. That packet has $ip_options of 0 so this may need closer inspection.

For reference, tcpflow has a similar issue at simsong/tcpflow#142 (open at this time).