Page MenuHomeFreeBSD

ossl: Don't encryt/decrypt too much data for chacha20.

Authored by jhb on Mar 31 2021, 5:26 PM.
Referenced Files
Unknown Object (File)
Dec 30 2022, 1:38 PM
Unknown Object (File)
Dec 14 2022, 2:48 AM
Unknown Object (File)
Dec 12 2022, 2:19 AM
Unknown Object (File)
Dec 12 2022, 2:03 AM



The loops for Chacha20 and Chacha20+Poly1305 which encrypted/decrypted
full blocks of data used the minimum of the input and output segment
lengths to determine the size of the next chunk ('todo') to pass to
Chacha20_ctr32(). However, the input and output segments could extend
past the end of the ciphertext region into the tag (e.g. if a "plain"
single mbuf contained an entire TLS record). If the length of the tag
plus the length of the last partial block together were at least as
large as a full Chacha20 block (64 bytes), then an extra block was
encrypted/decrypted overlapping with the tag. Fix this by also
capping the amount of data to encrypt/decrypt by the amount of
remaining data in the ciphertext region ('resid').

Reported by: gallatin
Sponsored by: Netflix

Diff Detail

rS FreeBSD src repository - subversion
No Lint Coverage
No Test Coverage
Build Status
Buildable 38219
Build 35108: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Mar 31 2021, 5:26 PM

Drew had a panic in production where the relevant mbuf had a cipher text payload of 0x1b7 bytes in length. I was able to reproduce with a size of 112 (one full block plus enough of a partial block that the poly1305 hash equaled a second full block). I've tested this fix with both sizes. The following review for cryptocheck expands the sizes covered to handle this case, but it in a slightly more general way.

This revision is now accepted and ready to land.Mar 31 2021, 6:09 PM