GHSA-5pj7-wx9m-cjh6: 
PHP vulnerability analysis and mitigation

Impact

ConcatKDF::generate(), the key derivation function behind the ECDH-ES and ECDH-SS key agreement algorithms, computes a single SHA-256 round and truncates it to the requested length. It never returns more than 32 bytes. The Concat KDF that RFC 7518 (section 4.6.2) takes from NIST SP 800-56A concatenates as many rounds as needed to reach the requested key length. In direct key agreement mode ("alg": "ECDH-ES"), the derived key is the content encryption key (CEK). The AES-CBC-HMAC-SHA2 algorithms split it into MAC_KEY followed by ENC_KEY (RFC 7518, section 5.2.2.1). With a 32-byte CEK:

• A256CBC-HS512 expects 64 bytes. The 32 bytes all become MAC_KEY and ENC_KEY is empty. PHP's OpenSSL extension pads a short key with zero bytes, so the content is encrypted under an all-zero AES-256 key. Anyone who obtains the token can decrypt it, without the recipient's private key.
• A192CBC-HS384 expects 48 bytes. ENC_KEY is made of 8 secret bytes followed by 16 zero bytes: the content key has 64 bits of strength instead of 192. MAC_KEY stays secret, so integrity is not affected. The loss is the confidentiality of the tokens the library produces. Neither the builder nor the decrypter checked the length of a key obtained by key agreement, and both derived the same short key, so round trips within the library succeeded. Conforming implementations cannot decrypt the tokens produced this way, and the library cannot decrypt the tokens they produce with these two algorithms.

Affected configurations

JWE produced with alg set to ECDH-ES and enc set to A256CBC-HS512 (content readable by anyone) or A192CBC-HS384 (64-bit content key), whatever the curve. This was measured with P-256, P-521 and X25519. The non-registered ECDH-SS algorithm shares the same derivation. Not affected: A128CBC-HS256, A128GCM, A192GCM, A256GCM, and the key wrapping variants ECDH-ES+A128KW, ECDH-ES+A192KW and ECDH-ES+A256KW. They all request 256 bits or less, which a single round covers. The defect has been present since the first release of the library.

Patches

ConcatKDF::generate() now concatenates as many SHA-256 rounds as the requested length needs. JWEBuilder and JWEDecrypter now check the length of a key obtained by key agreement, as they already did for wrapped and encrypted keys. Compatibility. The fix changes the key derived for ECDH-ES with A192CBC-HS384 and A256CBC-HS512:

• tokens produced with these combinations before the upgrade cannot be decrypted after it, and have to be issued again;
• a patched party and an unpatched one cannot exchange such tokens, so producers and consumers have to be upgraded together;
• tokens produced by other conforming implementations can now be decrypted.

Workarounds

Until you upgrade, encrypt with ECDH-ES and A128CBC-HS256 or A128GCM/A192GCM/A256GCM, or use ECDH-ES+A128KW/ECDH-ES+A192KW/ECDH-ES+A256KW. Consider the content of every token already produced with ECDH-ES and A256CBC-HS512 as disclosed, and the content of the tokens produced with ECDH-ES and A192CBC-HS384 as weakly protected.

References

• RFC 7518, section 4.6.2 (Key Derivation for ECDH Key Agreement), sections 5.2.2.1 and 5.2.5
• NIST SP 800-56A, section 5.8.1 (Concatenation Key Derivation Function)

Credits

Reported by Jeroen Robben.