- start decoding when we have eapol1+2 packets
Do not insist on a complete captured handshake, decode what we can.
- more robust way to detect eapol #2 packets
At least Win 10 is violating the spec on rekey by setting the secure
bit in #2. Unpatched version shows and handles #2 as #4, breaking
decoding after rekey.
- fixed eapol rekey key handling
Inital patch (see https://code.wireshark.org/review/8268)
is adding redundant keys, since it scans all the time
and not only once.
- ignore tailing garbage after eapol sections in frame
See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9065#c8
Included testcase to test decode for incomplete handshakes and eapol2
packets with secure bit set on rekey.
Ping-Bug: 9065
Change-Id: Id775088db9b5aaa80da9efdeed6902d024b5c0cd
Reviewed-on: https://code.wireshark.org/review/11484
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Do not leak the key and SSID. Note that there are still some leaks in
the GTK UI related to get_wireshark_keys(), but I did not track them
down.
Caught by LeakSanitizer.
Change-Id: I639166e6ea457605d6ae0ebd58e56d7594a7b7db
Reviewed-on: https://code.wireshark.org/review/10860
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Using memcpy with overlapping buffers is not safe; use memmove instead
Bug: 11549
Change-Id: I8e15eb0af38d325a5e67e8748008126ac5994588
Reviewed-on: https://code.wireshark.org/review/10652
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
AirPDCapPacketProcess() really does two different things; some of the
stuff it does in both code paths only needs to be done in one code path.
Make it so.
Change-Id: Idb231d729150781f323e88ed375c983a3afd2577
Reviewed-on: https://code.wireshark.org/review/10439
Reviewed-by: Guy Harris <guy@alum.mit.edu>
AES keys must be at least 128 bits; AES_unwrap returns a null pointer if
handed a too-short key, and we then just dereference that null pointer
and crash. Just give up with a too-short key.
Bug: 11507
Change-Id: Id1cf0a43c608597a11ff9df40f3654e6ff30619d
Reviewed-on: https://code.wireshark.org/review/10422
Reviewed-by: Guy Harris <guy@alum.mit.edu>
AirPDcapStoreSa() was assuming that ctx->first_free_index would always
be within the ctx->sa array; nothing guarantees that. Fail if it's past
the end of the array; that means there *are* no free indices.
Change-Id: I73145ea3f3dda1b3800a41fa3a2b01ac344dcbfc
Reviewed-on: https://code.wireshark.org/review/9634
Reviewed-by: Guy Harris <guy@alum.mit.edu>
A call of the 'memcpy' function will lead to the '& tmp_key' buffer becoming out of range.
Change-Id: I615a6c3e0dab8cfc2d240b6b39cff387e0689f35
Reviewed-on: https://code.wireshark.org/review/8796
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
While we are at it, put back some debug logs that were removed in g1439eb6 (otherwise msgbuf is no more initialized)
Change-Id: Ie34c4f2e638bc3ee77a0565446de37a15385dc0d
Reviewed-on: https://code.wireshark.org/review/8389
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
In AirPDcapRsnaPwd2PskStep(), digest[] holds an SSID plus 4 bytes of
count, so the size is MAX_SSID_LENGTH plus 4, and digest1[] holds an
SHA-1 digest, so the size is SHA1_DIGEST_LEN.
That makes it a bit clearer why those are the sizes.
Change-Id: I58ed6643f57675375f7f369470d600382323315f
Reviewed-on: https://code.wireshark.org/review/8387
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Have it allocate the buffer for the unwrapped key and return a pointer
to it, rather than having it be handed a buffer for that key.
That makes it a bit easier to validate, in AES_unwrap, that we don't
write past the end of the buffer.
Change-Id: Id02852c23054b3ed33eeeb383e7aa6cf12d02ed9
Reviewed-on: https://code.wireshark.org/review/8371
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Hopefully that'll make it a little easier to make sure that we're not
overflowing arrays.
Change-Id: I770df045ef9a45fd486c1271ea424b3334bb39d2
Reviewed-on: https://code.wireshark.org/review/8370
Reviewed-by: Guy Harris <guy@alum.mit.edu>
g1439eb6 changed AIRPDCAP_WPA_PSK_LEN from 64 bytes to 32 bytes, leading to a stack corruption in AirPDcapRsnaPwd2Psk() function
Change-Id: Ibf51f6749715055cd84906a144214ed44c85256b
Reviewed-on: https://code.wireshark.org/review/8358
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
This patch extends the existing decryption support for WPA to also
handle rekeys by checking each decrypted packet for a 4-way-handshake.
Rekeys can be used for WPA-PSK, but are more common with WPA-Enterprise
(WPA-EAP).
For decrypting WPA-EAP secured packets the user must provide all used PMK's
of the connection (aka PSK's) as WPA-PSK 32 byte hex values to wireshark
via the existing interface.
(The capture must have all 4-way-handshakes included also, starting with
the first unencrypted one.)
Every decrypted unicast packet will habe the used PMK and TK shown in the
CCMP/TKIP section below the key index in the GUI. Group packets will display the
GTK instead.
Additionally this fixes a small issue with group rekey handling, so every packet
can be selected in the GUI in random order, removing the need to manually find
the correct group keying packets prior to that.
It was tested primary with WPA-CCMP, but TKIP is also working.
One section in the code touch bluetooth 802.1X support. It should do
exactly the same, but will now also examine all decypted packets for rekeys.
Ping-Bug: 11172
Change-Id: I19d055581fce6268df888da63485a48326046748
Reviewed-on: https://code.wireshark.org/review/8268
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The sha1 function outputs a multiple of 20 bytes while the ptk buffer
has only a size of 64 bytes. Follow the hint in 802.11i-2004, page 164
and use an output buffer of 80 octets.
Noticed when running Wireshark with ASAN, on exit it would try to free a
"next" pointer which was filled with sha1 garbage. It probably got
triggered via 3f8fbb7349 which made
AirPDcap responsible for managing its own memory.
Bug: 10849
Change-Id: I10c1b9c2e224e5571d746c01fc389f86d25994a1
Reviewed-on: https://code.wireshark.org/review/7645
Reviewed-by: Evan Huus <eapache@gmail.com>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Michael Mann <mmann78@netscape.net>
(The other calls are just wrapped in macros)
Change-Id: I6a029dddf7742ba95510ec24cec30553461e48c6
Reviewed-on: https://code.wireshark.org/review/6558
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Most of the remaining ep_ uses are grouped with specific functionality.
Change-Id: I8fa64a17acc6bcdcf6891b2d28715ac0c58f1a4a
Reviewed-on: https://code.wireshark.org/review/6484
Reviewed-by: Michael Mann <mmann78@netscape.net>
A little bit of guess work is involved as the group key can use a
different cipher to the pairwise key, and we are trying to do this
purely based on the EAPOL messages with no prior knowledge of the
associate request. We try to guess the cipher based on the lengths.
Bug:8734
Change-Id: I4c456b45939c00a9d1122406891f704fa037349c
Reviewed-on: https://code.wireshark.org/review/3183
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
(Copyright or info about file...)
Change-Id: I90ba8b1c3ec8406b0c3365a69a8555837fc4bbb1
Reviewed-on: https://code.wireshark.org/review/515
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
obvious that the returned string is ephemeral, and opens up the original names
in the API for versions that take a wmem pool (and thus can work in any scope).
svn path=/trunk/; revision=54249
airpdcap.c:470:18: error: declaration of 'address' shadows a global declaration [-Werror=shadow]
airpdcap.c:611:18: error: declaration of 'address' shadows a global declaration [-Werror=shadow]
svn path=/trunk/; revision=53216
airpdcap.c:131:11: error: parameter 'password' not found in the function declaration [-Werror,-Wdocumentation]
* @param password [IN] pointer to a password (sequence of between 8 and
^~~~~~~~
airpdcap.c:154:11: error: parameter 'password' not found in the function declaration [-Werror,-Wdocumentation]
* @param password [IN] pointer to a password (sequence of between 8 and
^~~~~~~~
svn path=/trunk/; revision=51254
Needed to convert use of old IEEE802.11 preference strings to UAT. Since UAT is self-contained within its own file, the entire preference file doesn't need to be rewritten/saved when UAT values are changed.
svn path=/trunk/; revision=48308
airpdcap: For FromDS and ToDS both set use magic
All 802.11 data frames on the AMP link shall be sent with ToDS and FromDS
bits in the Frame Control field both set to one. Currently for this packets
we get different associations for the same EAPOL sequence since addr2 and
addr1 change.
svn path=/trunk/; revision=45923
Add 802.11 AMP LLC/SNAP header
Add LLC/SNAP header specified in BLUETOOTH SPECIFICATION Version 4.0 [Vol 5]
802.11 Protocol Adaptation Layer Functional Specification.
The SNAP header composed of the OUI of the Bluetooth SIG and the protocol
identifier given in spec mentioned shall be used to distinguish AMP 4-way handshake
messages from external security traffic. Decode this traffic as 802.1X authentication.
Part of
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7633
svn path=/trunk/; revision=45920
In order to compile the whole project with -DG_DISABLE_DEPRECATED
the mate plugin needs to replace its usage of GMemChunk.
All other places should be clean.
svn path=/trunk/; revision=38392
Removed "key prefix" need within GUI so it's a little more intuitive (because
that's what this bug is complaining about). Slight backwards compatibility
issue with UAT (because key prefix was in previous keys), but all development
(including fix for BUG 1123 that created UAT) has just been on SVN and not
released.
Also adjusted AirPCap (airpcap_loader.c) to account for the lack of "key
prefix".
Addressed some memory leaks/excess string creation.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5985
svn path=/trunk/; revision=37888
Alexander Wetzel