spp_frag2 bug (Re: [Snort-devel] IP dgm len < IP Hdr len Alert question)
cmg at ...402...
Mon May 12 07:28:10 EDT 2003
Jason_Royes <jroyes at ...1975...> writes:
> Something seems wrong with line 1227 of spp_frag2.c (snort-2.0.0):
> defrag_pkt->iph->ip_len = htons(defrag_pkt->pkth->len);
> defrag_pkt->pkth->len is set to the caplen in 1216:
> defrag_pkt->pkth->caplen = ETHERNET_HEADER_LEN + ft->calculated_size +
> defrag_pkt->pkth->len = defrag_pkt->pkth->caplen;
You are correct about the line 1227 problem wrapping around. We also
need to truncate the caplen in case of the 64k IP Packet size for the
underlying pcap problem ( savefile.c IIRC ).
> The first problem here is that ip_len, a 16bit quantity, is being
> assigned a 32bit quantity. This means ip_len will always be 14 bytes
> bigger than it should and will overflow when caplen >= 65536.
> Could this be fixed by changing 1227 to read something like:
> defrag_pkt->iph->ip_len = htons(defrag_pkt->pkth->len -
Yup. I'll test this out today.
> That may break reassembly for different data link types though.
The decoder structure needs to be revamped to take the different DLT's
into account for rebuilding so everything ends up looking the same.
> I suspect this is the cause for John Weidley's problem... see:
> The pcap savefile header length will be correct in the dump (though
> libpcap imposes a limit of 65535 on packet size) but the ip header
> length will be truncated to 16bits. After fixing spp_frag2.c,
> tcpdump will still not be capable of reading the dump without source
Chris Green <cmg at ...402...>
More information about the Snort-devel