Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 11527] Buildbot crash output: fuzz-2015-09-14-12129.pcap

[bugzilla-daemon@xxxxxxxxxxxxx]

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.