Large pac causes gss_accept_sec_context to fail

[Greg Hudson]

On 10/14/20 2:24 PM, Martijn de Gouw wrote:
> I've found a redhat article about 
> disabling pac data: https://access.redhat.com/solutions/969123.

I don't have access to read that, unfortunately.

> The token is very big for those users (~7k). I did some tracing in the 
> krb5 library to see what really goes wrong here, since the error is not 
> very descriptive. I was able to dig down in 
> src/lib/krb5/asn.1/asn1_encode.c, where the token is decoded. There is a 
> lot of decode_atype() performed on the token, until finally omit_atype() 
> returns ASN1_MISSING_FIELD, called by get_tag() for a->type = 
> atype_sequence (embedded in a type atype_tagged_thing tag, I think?).

What kind of object is being decoded?  That is, in the stack trace, what
is the entry point into the ASN.1 code?  It would have a name like
decode_krb5_ap_req().

In src/lib/krb5/asn.1/README.asn1 there is a section on debugging at the
end.  It provides a (laborious) process for determining where an error
like this is occurring within the ASN.1 type definition.

> Now I'm wondering is MS is really doing something wrong here, or krb5 is 
> unable to handle this PAC data. the 'net ads kerberos pac dump' does not 
> complain or show any errors when dumping PAC data for any user.

PAC data isn't encoded in ASN.1; the code to process it lives in
src/lib/krb5/krb/pac.c.  The issue is likely in the surrounding Kerberos
protocol object.  It could be a truncation issue as Simo hypothesizes,
although I would expect that to normally yield a different error like
ASN1_OVERRUN.