On Oct 8, 2015, at 11:33 AM, Michael Richardson <m...@sandelman.ca> wrote:
> <fx.leb...@yahoo.com> wrote:
>> Using pcap_major_version() and pcap_minor_version()) in tcpdump when
>> reading a file, I found:
>
>> Most pcap file have major.minor: 2.4 (current PCAP_VERSION_MAJOR and
>> PCAP_VERSION_MINOR),
>
>> a few have: 1.0 (ahcp.pcap, hdlc_slarp.pcap, msnlb2.pcap,
>> of10_7050q.pcap and ospf3_auth.pcap), one have: 12336.12336
>> (cve2015-0261-crash.pcap), doubtless via fuzzing.
>
>> To avoid case like the last, I'm thinking of adding a sanity check on
>> major/minor.
>
>> Hence my question:
>
>> What are the pairs major / minor to authorize currently?
>
> I think that as long as major <= PCAP_VERSION_MAJOR, we are good.
We might also want to, if major == PCAP_VERSION_MAJOR, make sure minor <=
PCAP_VERSION_MINOR, just in case somebody does a pcap 2.5 that code that only
knows up to version 2.4 can't handle.
Given the common convention of "change a major version if code that handles the
new version would have to use a different code path to read the old version,
change a minor version if code that handles the new version can still handle
the old version but code that only knows about the old version can't handle the
new version", we should require major == PCAP_VERSION_MAJOR, but, as libpcap
never had such a check, perhaps whatever versions 1 (or 0, if there was a
version 0) looked like, the code to handle version 2 can read them, so I
wouldn't add a requirement that major == PCAP_VERSION_MAJOR.
We also have a special case for a major version of 543, which was the bright
idea of somebody at Data General:
* In addition, DG/UX tcpdump writes out files with a version
* number of 543.0, and with the caplen and len fields in the
* pre-2.3 order.
and we should continue to handle that.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
