https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16252
Bug ID: 16252
Summary: Some valid erf timestamps get confused for gzip magic
header bytes and causes an error with file_seek
Product: Wireshark
Version: 3.0.6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: Major
Priority: Low
Component: TShark
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 17500
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17500&action=edit
an erf file that is confused with only one gzip magic header byte
Build Information:
TShark (Wireshark) 3.0.6 (Git commit 908c8e357d0f)
Copyright 1998-2019 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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) without libpcap, with GLib 2.56.4, with zlib 1.2.11, without
SMI, without c-ares, without Lua, without GnuTLS, with Gcrypt 1.8.1, without
Kerberos, without MaxMind DB resolver, without nghttp2, without LZ4, without
Snappy, without libxml2.
Running on Linux 4.15.0-70-generic, with Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz
(with SSE4.2), with 31891 MB of physical memory, with locale en_US.utf8, with
Gcrypt 1.8.1, with zlib 1.2.11, binary plugins supported (0 loaded).
Built using gcc 7.4.0.
--
Lets say you have an erf file with the first two bytes set to 31 (0x1f) and 0x0
which would be valid values for the fractional second part of the erf header.
In the course of loading this file the program gets to
wiretap/file_wrappers.c:659 in the gz_head function. It sees that the first
byte is indeed 31 and decrements state->in.avail and increments the pointer
state->in.next. Then, it checks if the next byte is 139 (0x8B) and it is not,
so it skips ahead to wiretap/file_wrappers.c:761.
Because of this state->in.avail and state->in.next manipulation, the value that
is passed along for in_pos at wiretap/file_wrappers.c:762 is 1 and not the
expected 0. This is stored in the fast_seek data structure. Because most of
the open_routines at file_access.c:350 do not use more than 4096 bytes to
identify files, the file_seek at file_access.c:936 is able to successfully
rewind to the beginning of the buffer because it's not using the fast_seek
information.
The problem comes in when it reaches dbs_etherwatch_open which looks at more
than 4096 bytes. Then the file_seek function executes the if block at
wiretap/file_wrappers.c:1111 and the variable off at
wiretap/file_wrappers.c:1136 is equal to 1 when it should equal 0. This 1 is
passed to ws_lseed64 and causes all further reads of this buffer to start at
the second byte of the file instead of the first.
When this buffer is eventually passed to erf_open, it's not able to correctly
identify it as a valid erf file because it's missing the first byte.
You can duplicate this error with the attached file using tshark
tshark -r bad-erf-test.erf -2
If you leave off the -2 argument it is able to successfully read the file. I'm
not sure why this is.
Also, I can imagine a real but very rare situation where an erf timestamp in a
file would start with 0x1F and 0x8B.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:[email protected]?subject=unsubscribe
