Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 10523] New: 6LoWPAN extension headers not padded correctly

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	10523
Summary	6LoWPAN extension headers not padded correctly
Product	Wireshark
Version	1.99.x (Experimental)
Hardware	x86
OS	Windows 7
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	kevin.bracey@arm.com

Created attachment 13117 [details]
Packet with compressed Destination Options header padding

Build Information:
Version 1.99.0xxxxxxx (v1.99.0-rc1-1946-g712d9af from master)

Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> 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 (32-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
WinPcap (4_1_3), with libz 1.2.5, with GLib 2.38.0, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos,
with GeoIP, with PortAudio V19-devel (built Sep 26 2014), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), with GnuTLS 2.12.18, with Gcrypt 1.4.6, without AirPcap.
Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz (with SSE4.2), with 16068MB of
physical memory.


Built using Microsoft Visual C++ 10.0 build 40219

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
6LoWPAN packets can contain "compressed" IPv6 Extension Headers, as per RFC
6282, section 4. These headers aren't really compressed apart from the ability
to elide trailing padding in some cases; really they just maintain the
contiguous "compressed header" chain up to the next really compressed header
(IPv6/UDP).

The key difference in the compressed extension header format is that the length
is stored in octets, rather than 8-octet units. This permits a trailing Pad1 or
PadN option that was used to get 8-octet alignment in a Hop-by-Hop or
Destination Option header to be elided. Key paragraph from RFC 6282:

   IPv6 Hop-by-Hop and Destination Options Headers may use a trailing
   Pad1 or PadN to achieve 8-octet alignment.  When there is a single
   trailing Pad1 or PadN option of 7 octets or less and the containing
   header is a multiple of 8 octets, the trailing Pad1 or PadN option
   MAY be elided by the compressor.  A decompressor MUST ensure that the
   containing header is padded out to a multiple of 8 octets in length,
   using a Pad1 or PadN option if necessary.  Note that Pad1 and PadN
   options that appear in locations other than the end MUST be carried
   in-line as they are used to align subsequent options.

However, Wireshark does not decompress the packet strictly correctly. It simply
zero-pads all 6LoWPAN NHC extension headers up to a multiple of 8 octets. As
can be seen in this trace, that is then dissected as having multiple Pad1
options.

Compressed header in attached trace:
E7 02 1E 00  
(E7: NHC Destination Options Header, Next Header Compressed)
(02: Header Length 2 octets)
(1E 00: Experimental option, zero-length payload)

Wireshark decompression:
11 00 1E 00 00 00 00 00
(11: Next Header UDP)
(00: Header Length 8 octets)
(1E 00: Experimental option, zero-length payload)
(00 00 00 00: Pad1 Pad1 Pad1 Pad1)

Correct decompression (only possible compressor input that could produce trace
packet by RFC 6282 rules):
11 00 1E 00 01 02 00 00
(11: Next Header UDP)
(00: Header Length 8 octets)
(1E 00: Experimental option, zero-length payload)
(01 02 00 00: PadN, 2 bytes payload)

[Note that Wireshark's decompression result is not strictly compressible by RFC
6282, as it has multiple trailing Pad1s - you couldn't even strictly compress
the last Pad1, by my reading].

How you decompress the padding matters for two reasons:

1) Incorrect padding expansion would cause an IPsec authentication failure.
Padding options are included in IPsec header processing (they're non-mutable
options).

2) A simple zero-padding rule can encourage compression implementations to be
lax on their compression, and compress data other than padding. For example:

Uncompressed IPv6 extension header:
11 00 1E 04 00 00 00 00
(11: Next Header UDP)
(00: Header Length 8 octets)
(1E 04 00 00 00 00: Experimental option, 4 bytes payload, all zeros)

Possible over-zealous compression that Wireshark currently silently accepts and
decompresses to original by zero padding:
E7 02 1E 04  
(E7: NHC Destination Options Header, Next Header Compressed)
(02: Header Length 2 octets)
(1E 04: Experimental option, four bytes payload, payload elided)

Such a zero-byte-eliding compression/decompression is natural "no-extra-code
optimisation" for an implementation that actually compresses+decompresses
IPHC+NHC headers to full IPv6, but would trip up an implementation that
actually parses compressed extension headers in place. Futher, the compression
does not work on simple RFC 6282-compliant decompressors:

"Incorrect" decompression of above by simple RFC 6282-compliant decompressor
that doesn't check whether elided bytes are padding or not:
11 00 1E 04 01 02 00 00
(11: Next Header UDP)
(00: Length 8 octets)
(1E 04 01 02 00 00: Experimental option, 4 bytes payload, 01 02 00 00)

Such zero-payload-eliding compressor/decompressor implementations have been
observed.

So, some possible further strict-checking refinements, beyond just using PadN:

1) Output a warning if more bytes are needed for any header other than
Destination or Hop-by-Hop Option headers. (The other headers don't have
pure-option payloads).

2) Output a warning if adding bytes to a Dest/Hop-by-Hop header that doesn't
contain an already-well-formed Option chain, or already ends in another
Pad1/PadN.

3) If the above strict checks fail, as well as the warning, you could maybe
zero-pad rather than PadN-pad to preserve the "compress-zero-payload" intent of
the non-RFC-6282 compressors.

---

      You are receiving this mail because:

• You are watching all bug changes.