| Bug ID |
10416
|
| Summary |
SSL/TLS dissector incorrectly interprets length for status_request_v2 hello extension
|
| Product |
Wireshark
|
| Version |
1.12.0
|
| Hardware |
x86
|
| OS |
Linux (other)
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 13016 [details]
packet trace of TLS connection to Apache 2.2.15 server with status_request and
status_request_v2 in ClientHello
Build Information:
wireshark 1.12.0 (Git Rev Unknown from unknown)
Copyright 1998-2014 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 (32-bit) with GTK+ 2.20.1, with Cairo 1.8.8, with Pango 1.28.1, with
GLib 2.26.1, with libpcap, with libz 1.2.3, without POSIX capabilities, without
libnl, without SMI, without c-ares, without ADNS, without Lua, without Python,
without GnuTLS, without Gcrypt, with MIT Kerberos, without GeoIP, without
PortAudio, with AirPcap.
Running on Linux 2.6.32-431.5.1.el6.i686, with locale en_US.utf8, with libpcap
version 1.4.0, with libz 1.2.3, without AirPcap.
Built using gcc 4.4.7 20120313 (Red Hat 4.4.7-4).
--
When interpreting a TLS ClientHello with the status_request_v2 extension, the
SSL dissector incorrectly interprets the length associated with the
certificate_status_req_list field as a 24-bit integer rather than a 16 bit.
The subsequent advance of the offset by 3 bytes causes the dissection of the
CertificateStatusRequestItemV2 entries to be interpreted incorrectly since the
offset doesn't start at the beginning of the structure. Based on the
definition in RFC 6961:
struct {
CertificateStatusRequestItemV2
certificate_status_req_list<1..2^16-1>;
} CertificateStatusRequestListV2;
This length should be 2 bytes long.
Also the list_len while loop decrements by a single byte at a time rather than
by the number of bytes for a CertificateStatusRequestItemV2. This causes the
dissector to advance past the end of the status_request_v2 extension into any
following extensions or past the end of the packet altogether. The result is
that the trace has a malformed packet error.
A sample capture showing a ClientHello sent to a server that doesn't support
any status_request[_v2] extension has been attached.
Below is a sample fix that has been briefly tested on a modified 1.12.0 build.
It parses the status_request_v2 extension and does not have malformed packet
errors.
epan/dissectors/packet-ssl-utils.c:
5253,5254c5253,5254
< list_len = tvb_get_ntoh24(tvb, offset);
< offset += 3;
---
> list_len = tvb_get_ntohs(tvb, offset);
> offset += 2;
5256c5256,5257
< while (list_len-- > 0)
---
> while (list_len > 0) {
> guint32 prev_offset = offset;
5257a5259,5260
> list_len -= (offset - prev_offset);
> }
You are receiving this mail because:
- You are watching all bug changes.