https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4758
Summary: Check HTTP Content-Length parsing for overflow
Product: Wireshark
Version: 1.2.8
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: doj@xxxxxxxxx
Created an attachment (id=4634)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4634)
check Content-Length strtoll() for overflow in HTTP dissector
Build Information:
TShark 1.2.8
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> 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 (32-bit) with GLib 2.20.3, with libpcap 1.1.1, with libz 1.2.3, with
POSIX capabilities (Linux), with libpcre 7.7, without SMI, without c-ares,
without ADNS, with Lua 5.1, with GnuTLS 2.1.8, with Gcrypt 1.4.0, without
Kerberos, without GeoIP.
Running on Linux 2.6.28.10, with libpcap version 1.1.1, GnuTLS 2.1.8, Gcrypt
1.4.0.
Built using gcc 4.3.4.
--
The HTTP dissector uses strtoll() to convert the Content-Length string into a
64bit variable. But that string can contain a number larger (or less) than
64bit, which lets the strtoll() return INT_MAX (or INT_MIN). strtoll() then
indicates this with errno==ERANGE.
The attachted patch checks if errno is set this way and then treats that HTTP
Content-Length as unspecified, since we don't know the real size.
I haven't checked other occurences of strtoll() in the HTTP dissector if they
could benefit from the errno check, or if other dissectors could use it.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
