[gnutls-dev] Re: Minor libtasn1 bug

[Simon Josefsson]

Stephen Wrobleski <steve at localtoast.org> writes:

> I've come across a relatively minor bug in libtasn1-0.3.5. In the following
> snippet, I first find out how long of a buffer is necessary, allocate
> exactly that size buffer, and then do the real coding.
>
> {
>   char *der, *err;
>   int  der_len, ret;
>
>   /* find out the size of the coding */
>   der_len = 0;
>   ret = asn1_der_coding(hashkey, "", NULL, &der_len, err);
>   assert(ret == ASN1_MEM_ERROR);
>
>   der = malloc(der_len);
>
>   ret = asn1_der_coding(hashkey, "", der, &der_len, err);
>   assert(ret == ASN1_SUCCESS);
> }
>
> The second asn1_der_coding() call fails, complaining about too short of a
> buffer length. I've only seen this happen when I'm attempting to encode a
> NULL type (it's also implicitly tagged, by the way). I've looked in the
> source for 0.3.5, as well as the cvs version as of 18SEP2006, and believe
> the problem to be the lines
>
> if (max_len >= 0)
>   der[counter++] = 0;
>
> in the TYPE_NULL coding section of the function itself (in coding.c).
> Specifically, every other section increments 'counter' regardless of whether
> we write to the buffer or not. This section doesn't.
>
> I'm running against the Debian binary package (0.3.5-2). As this problem is
> pretty easy to work around (for now), I've resisted building from source. I
> think this should be pretty easy to independently verify and fix. Please let
> me know if more information happens to be required.

Your analysis looks correct to me, and the code looks wrong.  I've
fixed this in CVS, for 0.3.7.

Thanks,
Simon