
Crypto Vulnerabilities in AWS S3 SDK - cryptbe
https://twitter.com/SchmiegSophie/status/1292930639772004352
======
cryptbe
The last vulnerability [1] is super cool, as it allows to decrypt AES-GCM
ciphertexts using an AES-CBC padding oracle!

The exploit is very efficient and fits in a tweet:

1\. Take C = E(K, IV) \xor P from GCM encryption

2\. Make a guess of P, send (IV \ xor PADDING) || (C \xor P_guess) to the CBC
oracle where PADDING is a fixed constant. If the oracle returns that the
padding is correct, P_guess is correct. Otherwise make another guess.

The root cause of the issue runs pretty deep. It's a class of crypto
vulnerabilities we called "in-band protocol negotiation". That is, the
ciphertext contains protocol-related parameters that determine how it should
be decrypted. The JWT standard has this issue, which has led to countless
"alg": "none" vulnerabilities. JWT is not alone, this mistake is presented in
many other libraries or standards.

I wrote about how we avoid this issue in Tink [2] [3]:

>2/ A key in Tink contains not only the raw key material, but also all
necessary parameters. It is equivalent to the result of a handshake. Before
any data encryption can take place, both sides have to reach an agreement not
only on a raw key, but also how to use that key to encrypt data. Since a key
in Tink contains all parameters, Tink does not require in-band ciphersuite
negotiation. That is no ciphertext in Tink contains any other metadata aside
from a key ID.

>This design sounds so simple but I've seen people get this wrong all the
time. For example, the root cause of many embarrassing vulnerabilities in JWT
[1] is in-band ciphersuite negotiation. That is, a JWT contains an alg field
that dictates how the receiver should process it. This alg field should rather
be included as part of the key.

>JWT is not the only standard making this mistake. Many crypto libraries only
ask users for the raw key material. This means the parameters are either
implicitly assumed or under specified. Aside from the aforementioned
vulnerabilities, this can also lead to key confusion, cross-protocol key reuse
and make it hard to rotate keys or change algorithms.

>To the best of my knowledge, Tink is the only high-level library that gets
this right.

[1] [https://github.com/google/security-
research/security/advisor...](https://github.com/google/security-
research/security/advisories/GHSA-7f33-f4f5-xwgw)

[2] [https://github.com/google/tink](https://github.com/google/tink)

[3]
[https://news.ycombinator.com/item?id=23215652](https://news.ycombinator.com/item?id=23215652)

