Wireshark-bugs: [Wireshark-bugs] [Bug 11527] Buildbot crash output: fuzz-2015-09-14-12129.pcap
Comment # 6
on bug 11527
from Peter Wu
The problem occurs in this code:
/* Unwrap the key; the result is key_bytes_len in length */
decrypted_data = AES_unwrap(decryption_key, 16, szEncryptedKey,
key_bytes_len);
/* With WPA2 what we get after Broadcast Key decryption is an actual RSN
structure.
The key itself is stored as a GTK KDE
WPA2 IE (1 byte) id = 0xdd, length (1 byte), GTK OUI (4 bytes), key
index (1 byte) and 1 reserved byte. Thus we have to
pass pointer to the actual key with 8 bytes offset */
key_found = FALSE;
key_index = 0;
while(key_index < key_bytes_len && !key_found){
guint8 rsn_id;
/* Get RSN ID */
rsn_id = decrypted_data[key_index];
if (rsn_id != 0xdd){ // <--- triggers valgrind
if (key_index+1 >= key_bytes_len){
return AIRPDCAP_RET_NO_VALID_HANDSHAKE;
}
key_index += decrypted_data[key_index+1]+2;
}else{
key_found = TRUE;
}
}
when valgrind was triggered, these are the values:
rsn_id = 0
key_found = 0
key_index = 50
key_version = 2
key_bytes_len = 56
key_len = 15
Looking at https://tools.ietf.org/html/rfc3394#page-5, it defines P1, ..., Pn
as the plaintext input and C0, C1, ..., Cn as the ciphertext output.
"cipher_text" in the AES_unwrap code supposedly corresponds to the "Plaintext"
of the RFC3394 algorithm. Then the "n" is off-by-one I think.
>From airpdcap_rijndael.c:
n = (cipher_len/8)-1; /* the algorithm works on 64-bits at a time */
n should not be minus 1 if the RFC 3394 algorithm is followed. I'll sleep a bit
and think about it.
You are receiving this mail because:
- You are watching all bug changes.
