AEADs/aes-gcm: Plaintext exposed in decrypt_in_place_detached even on tag verification failure (GHSA-423w-p2w9-r7vq)
Aliases: CVE-2023-42811
Published: 2023-09-22T16:11:47Z
Severity: type: CVSS_V3
score: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:H/A:N
Affected: [{'package': {'ecosystem': 'crates.io', 'name': 'aes-gcm'}, 'ecosystem_specific': {'affected_functions': ['']}, 'ranges': [{'type': 'ECOSYSTEM', 'events': [{'introduced': '0.10.0'}, {'fixed': '0.10.3'}]}], 'database_specific': {'last_known_affected_version_range': '<= 0.10.2'}}]

### Summary
In the AES GCM implementation of decrypt_in_place_detached, the decrypted ciphertext (i.e. the correct plaintext) is exposed even if tag verification fails. 

### Impact
If a program using the `aes-gcm` crate's `decrypt_in_place*` APIs accesses the buffer after decryption failure, it will contain a decryption of an unauthenticated input. Depending on the specific nature of the program this may enable Chosen Ciphertext Attacks (CCAs) which can cause a catastrophic breakage of the cipher including full plaintext recovery.

### Details
As seen in the implementation of [decrypt_in_place_detached](https://docs.rs/aes-gcm/latest/src/aes_gcm/lib.rs.html#309) for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via `buffer`. 

This should ideally not be the case - as noted in page 17 of[ NIST's publication _Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC_](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf): 
_In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise,FAIL is returned._

This is seems correctly addressed in the [AES GCM SIV implementation](https://docs.rs/aes-gcm-siv/latest/src/aes_gcm_siv/lib.rs.html#307), where the decrypted buffer is encrypted again before the error is returned - this fix is straightforward to implement in AES GCM. To ensure that these types of cases are covered during testing, it would be valuable to add test cases like [23, 24 ](https://github.com/google/wycheproof/blob/master/testvectors/aes_gcm_test.json#L288)etc from [project wycheproof ](https://github.com/google/wycheproof)to ensure that when a bad tag is used, there is an error on decryption _**and**_ that the plaintext value is not exposed. 

### PoC
To reproduce this issue, I'm using [test case 23](https://github.com/google/wycheproof/blob/master/testvectors/aes_gcm_test.json#L288) from project wycheproof. 
```rust
    let key = GenericArray::from_slice(&hex!("000102030405060708090a0b0c0d0e0f"));
    let nonce = GenericArray::from_slice(&hex!("505152535455565758595a5b"));
    let tag = GenericArray::from_slice(&hex!("d9847dbc326a06e988c77ad3863e6083")); // bad tag
    let mut ct = hex!("eb156d081ed6b6b55f4612f021d87b39");
    let msg = hex!("202122232425262728292a2b2c2d2e2f");
    let aad = hex!("");
    let cipher = Aes128Gcm::new(&key);
    let _plaintext = cipher.decrypt_in_place_detached(&nonce, &aad, &mut ct, &tag);
    assert_eq!(ct, msg);
```