(Bug) Buffer overrun in gcry_cipher_gettag
Peter Wu
peter at lekensteyn.nl
Wed Mar 23 03:25:12 CET 2016
On Tue, Mar 22, 2016 at 07:59:08PM -0400, Ian Goldberg wrote:
> On Tue, Mar 22, 2016 at 11:27:26PM +0100, Peter Wu wrote:
> > Ah, my bad. OCB happens to be unaffected, I included it because the code
> > is smaller than the GCM case. I originally triggered it with AES-GCM.
> > Please find minimal reproducers in the attached crash.c file.
>
> You didn't attach anything?
Oops, now I do.
It also found that the meaning of the tag length is not fixed.
For OCB the tag length can be 64, 96 or 128 bits (based on RFC 7253) so
the libgcrypt API allows you to specify the maximum buffer size.
Current implemented constraints:
* CCM: taglen == authlen
* cmac (as used by MAC-CMAC): 1 <= taglen <= block_size
* GCM: 16 <= taglen (bug!)
* OCB: ocb.taglen <= taglen (copy at most ocb.taglen)
* Poly1305: 16 <= taglen (bug!)
Anything outside this range results in one of the following errors:
* GPG_ERR_BUFFER_TOO_SHORT (GCM, OCB, Poly1305)
* GPG_ERR_INV_ARG (CCM, CMAC)
* GPG_ERR_INV_LENGTH (CCM)
I have some patches for the gettag crashes, but maybe it would also be
nice to be consistent here and treat the input size solely as a hint for
the input buffer size, and return failure if it is too small (instead of
too large)? Of course the documentation has to be updated for this.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.c
Type: text/x-c
Size: 1395 bytes
Desc: not available
URL: </pipermail/attachments/20160323/2af58ff4/attachment-0001.bin>
More information about the Gcrypt-devel
mailing list