| Bug ID |
12400
|
| Summary |
ICMPv6 dissector doesn't respect actual packet length
|
| Product |
Wireshark
|
| Version |
1.12.8
|
| Hardware |
x86-64
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14526 [details]
Sample generated by AFL
Build Information:
TShark 1.12.8 (v1.12.8-0-g5b6e543 from (HEAD)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GLib 2.48.0, with libpcap, with libz 1.2.8, with POSIX
capabilities (Linux), with libnl 3, without SMI, with c-ares 1.11.0, without
Lua, without Python, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT Kerberos,
with GeoIP.
Running on Linux 4.5.1-1-ARCH, with locale en_US.utf8, with libpcap version
1.7.4, with libz 1.2.8.
Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
Built using gcc 5.3.0.
--
This issue was uncovered with AFL (http://lcamtuf.coredump.cx/afl/)
It appears that when the packet length according to the IPv4 header is larger
than the actual packet the ICMPv6 dissector does not stop dissecting once it
reaches the end of the packet but continues on per the length in the IPv4
header.
The attached pcap file contains a single packet with the length field of the
IPv6 header set to 65535 (0xffff). When decoded with 'tshark -nxVr sample.pcap'
it generates ~222,722 lines out output. When the length is set correctly to
1406 (0x057e) it only generates ~144 lines.
Bug was discovered in but also exists in 1.12.10.
Any credit goes to Chris Benedict, Aurelien Delaitre, NIST SAMATE Project,
https://samate.nist.gov
You are receiving this mail because:
- You are watching all bug changes.