Wireshark-bugs: [Wireshark-bugs] [Bug 12699] New: IKEv1 decryption is unreliable, depending on p
| Bug ID |
12699
|
| Summary |
IKEv1 decryption is unreliable, depending on packet viewing order
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
x86-64
|
| OS |
Debian
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
mirko.parthey@web.de
|
Created attachment 14783 [details]
IKEv1 main mode, responder chooses the first transform
Build Information:
Version 2.3.0 (v2.3.0rc0-93-g8e60500 from master)
Copyright 1998-2016 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 (64-bit) with GTK+ 3.14.5, with Cairo 1.14.0, with Pango 1.36.8, with
libpcap, with POSIX capabilities (Linux), without libnl, with GLib 2.42.1, with
zlib 1.2.8, without SMI, with c-ares 1.10.0, without Lua, with GnuTLS 3.3.8,
with Gcrypt 1.6.3, with MIT Kerberos, without GeoIP, with PortAudio V19-devel
(built Feb 15 2014 23:28:00), without AirPcap.
Running on Linux 4.5.0-0.bpo.2-amd64, with locale de_DE.utf8, with libpcap
version 1.6.2, with GnuTLS 3.3.8, with Gcrypt 1.6.3, with zlib 1.2.8.
Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (with SSE4.2)
Built using gcc 4.9.2.
--
How to reproduce:
Install the IKEv1 decryption keys and load the first capture file
(ikev1-transform-option-1.pcapng), then perform the following steps.
- Open the ISAKMP subtree in the packet details pane.
- In the packet list pane, go to the last packet; decryption succeeds.
- Go to the first packet.
- Go to the last packet again: no decryption is performed.
Cause:
When the user selects frame #1 after viewing #10, it is dissected again and the
decryption algorithm in decr->encr_alg is set to each of the frame's transform
payloads in turn. When dissection is finished, decr->encr_alg is set to the
final transform seen in this frame. This happens to be the wrong one, since
the responder has chosen the first transform.
Returning to frame #10, the wrong encryption algorithm then fails the key
length check in decrypt_payload(), and decryption is not attempted.
The proper value for decr->encr_alg would have been the one from frame #2,
which contains the single chosen transform.
Suggested fix:
Make sure that the decryption algorithm is determined when Wireshark processes
the packets in sequence (first pass). The last transform seen in this sequence
is the correct one to use. In the example file, it is in frame #2. Also ensure
that the decryption algorithm is protected against changes after the first
pass.
Additional test case:
The second attachment (ikev1-transform-option-2.pcapng) can serve as another
regression test.
The relevant difference from the first is in frame #2, where the responder
chooses the second transform from the initiator's offer instead of the first.
The current code handles it correctly, even if just by coincidence,
and any bugfix must not break it.
You are receiving this mail because:
- You are watching all bug changes.
