1.8.2 KDCs segfaulting on authdata processing
Mike Roszkowski
roszkowski at wisc.edu
Fri Aug 27 14:08:39 EDT 2010
I've installed two 1.8.2 KDCs on RHEL5-64 that are supposed to replace our
current 1.4.x KDCs.
When I switched them into production, the KDCs crashed pretty regularly
processing TGS requests from machines in our AD domain (running on
Windows Server 2008 R1). Our MIT KDCs handle authentication for the AD domain.
Everything works fine with the 1.4.x KDCs so I don't think there's any
problems with the domain trust, etc.
The syslog entries for the crashes looked like this:
Aug 3 06:17:35 gingersnap kernel: krb5kdc[7155]: segfault at 0000000000000005
rip 0000000000416786 rsp 00007fffb177fc60 error 4
Aug 3 06:49:01 gingersnap kernel: krb5kdc[12914]: segfault at 000000000028042e
rip 0000000000416786 rsp 00007fff15c9bab0 error 4
Aug 3 06:57:56 gingersnap kernel: krb5kdc[14948] general protection rip:416786
rsp:7fff525d3a40 error:0
Aug 3 06:21:00 sugar kernel: krb5kdc[25955] general protection rip:416786
rsp:7fffd0e7a770 error:0
Aug 3 06:53:31 sugar kernel: krb5kdc[31689] general protection rip:416786
rsp:7fffb4f16a90 error:0
I was able to get a crash dump and syslog showed the following:
Aug 13 07:59:47 sugar kernel: krb5kdc[26180]: segfault at 0000000000000035 rip 0
000000000416786 rsp 00007fff6e2026b0 error 4
Here's the backtrace from the core file:
(gdb) bt
#0 is_kdc_issued_authdatum (context=0x14fbde00, authdata=0x31,
desired_type=128) at kdc_authdata.c:411
#1 0x000000000041688a in has_kdc_issued_authdata (context=0x14fbde00,
authdata=0x14fd8290) at kdc_authdata.c:456
#2 only_pac_p (context=0x14fbde00, authdata=0x14fd8290) at kdc_authdata.c:1136
#3 0x0000000000417076 in handle_signedpath_authdata (context=0x14fbde00,
flags=<value optimized out>, client=0x7fff6e202a40, server=0x7fff6e202aa0,
krbtgt=<value optimized out>, client_key=<value optimized out>,
server_key=0x7fff6e202ca0, krbtgt_key=0x14fd8e20, req_pkt=0x7fff6e2048f0,
request=0x14fd7b90, for_user_princ=0x0, enc_tkt_request=0x14fd9620,
enc_tkt_reply=0x7fff6e202b00) at kdc_authdata.c:1186
#4 0x00000000004161c0 in handle_authdata (context=0x14fbde00, flags=176,
client=0x7fff6e202a40, server=0x7fff6e202aa0, krbtgt=0x7fff6e2029e0,
client_key=0x14fd7540, server_key=0x7fff6e202ca0, krbtgt_key=0x14fd8e20,
req_pkt=0x7fff6e2048f0, request=0x14fd7b90, for_user_princ=0x0,
enc_tkt_request=0x14fd9620, enc_tkt_reply=0x7fff6e202b00)
at kdc_authdata.c:784
#5 0x0000000000408c31 in process_tgs_req (pkt=0x7fff6e2048f0,
from=0x7fff6e204900, response=0x7fff6e204918) at do_tgs_req.c:744
#6 0x0000000000405523 in dispatch (pkt=0x7fff6e2048f0, from=0x7fff6e204900,
response=0x7fff6e204918) at dispatch.c:90
#7 0x0000000000415599 in process_packet (conn=<value optimized out>,
selflags=<value optimized out>) at network.c:1298
#8 0x00000000004148e7 in service_conn () at network.c:1638
#9 listen_and_process () at network.c:1729
#10 0x000000000041320d in main (argc=1, argv=0x7fff6e204b68) at main.c:939
(gdb)
The problem appears to be that the enc_tkt_reply->authorization_data array
isn't terminated correctly:
gdb) p *enc_tkt_reply->authorization_data[0]
$2 = {magic = -1760647414, ad_type = 1, length = 67,
contents = 0x14fd81a0 "0A0??\004\002\002"}
(gdb) p *enc_tkt_reply->authorization_data[1]
$3 = {magic = -1760647414, ad_type = 1, length = 67,
contents = 0x14fda180 "0A0??\004\002\002"}
(gdb) p *enc_tkt_reply->authorization_data[2]
$4 = {magic = -1760647414, ad_type = 1, length = 67,
contents = 0x14fd9820 "0A0??\004\002\002"}
(gdb) p *enc_tkt_reply->authorization_data[3]
Cannot access memory at address 0x31
So, enc_tkt_reply->authorization_data[3] = 0x31, but it should either have
an allocated block of memory with an authdata item in it or a 0x00 to
terminate the authorization_data array.
The request authorization data looks like this:
(gdb) p *enc_tkt_request->authorization_data[0]
$6 = {magic = -1760647414, ad_type = 1, length = 67,
contents = 0x14fd7630 "0A0??\004\002\002"}
(gdb) p *enc_tkt_request->authorization_data[1]
$7 = {magic = -1760647414, ad_type = 1, length = 67,
contents = 0x14fd9770 "0A0??\004\002\002"}
(gdb) p *enc_tkt_request->authorization_data[2]
$8 = {magic = -1760647414, ad_type = 1, length = 54,
contents = 0x14fd97e0 "0402?\004\002\002\002"}
(gdb) p *enc_tkt_request->authorization_data[3]
Cannot access memory at address 0x0
And it looks like we have the following for request authdata:
authorization_data[0]: ad_type = KRB5_AUTHDATA_IF_RELEVANT
inside the item, we have ad_type = 141 (which doesn't have a
KRB5_AUTHDATA_ #define, but from google, it looks like it's
KERB_AUTH_DATA_TOKEN_RESTRICTIONS).
Inside that, we have what I assume is the KERB-AD-RESTRICTION-ENTRY.
Here are the raw contents:
(gdb) p *enc_tkt_request->authorization_data[0]
$12 = {magic = -1760647414, ad_type = 1, length = 67,
contents = 0x14fd7630 "0A0??\004\002\002"}
(gdb) x/67xb enc_tkt_request->authorization_data[0].contents
0x14fd7630: 0x30 0x41 0x30 0x3f 0xa0 0x04 0x02 0x02
0x14fd7638: 0x00 0x8d 0xa1 0x37 0x04 0x35 0x30 0x33
0x14fd7640: 0x30 0x31 0xa0 0x03 0x02 0x01 0x00 0xa1
0x14fd7648: 0x2a 0x04 0x28 0x01 0x00 0x00 0x00 0x00
0x14fd7650: 0x20 0x00 0x00 0x12 0x45 0x9d 0x93 0x95
0x14fd7658: 0x0f 0x23 0x2b 0xca 0xf9 0x8a 0x86 0xf5
0x14fd7660: 0x96 0x06 0xeb 0x79 0x5b 0x3e 0x3c 0x84
0x14fd7668: 0x87 0xda 0x3c 0x04 0x0b 0xee 0x9d 0xd5
0x14fd7670: 0xf0 0x0d 0x8c
authorization_data[1] is identical to authorization_data[0]
authorization_data[2]: ad_type = KRB5_AUTHDATA_IF_RELEVANT
inside that item, we have ad_type = 512 (KRB5_AUTHDATA_SIGNTICKET)
and inside that, we have the following, which doesn't quite look
like nested authdata, but what do I know?. Here are the raw contents:
(gdb) p *enc_tkt_request->authorization_data[2]
$14 = {magic = -1760647414, ad_type = 1, length = 54,
contents = 0x14fd97e0 "0402?\004\002\002\002"}
(gdb) x/54xb enc_tkt_request->authorization_data[2].contents
0x14fd97e0: 0x30 0x34 0x30 0x32 0xa0 0x04 0x02 0x02
0x14fd97e8: 0x02 0x00 0xa1 0x2a 0x04 0x28 0x30 0x26
0x14fd97f0: 0xa0 0x03 0x02 0x01 0x10 0xa1 0x1f 0x30
0x14fd97f8: 0x1d 0xa0 0x03 0x02 0x01 0x0c 0xa1 0x16
0x14fd9800: 0x04 0x14 0x4f 0xdd 0x1c 0x10 0x9e 0x9c
0x14fd9808: 0xb5 0x82 0xec 0xf4 0x81 0x28 0xf2 0xa0
0x14fd9810: 0xa0 0x78 0x70 0x48 0x8e 0xe9
With all the plug-ins that process the authdata and build the reply
authdata (handle_tgt_authdata and handle_kdb_authdata are called before
handle_signedpath_athdata, I think), I can't quite tell which one might
be corrupting enc_tkt_reply->authorization_data[3].
I was wondering if anyone has had similar problems with Krb5 1.8 processing
Windows authdata or any suggestions on isolating the cause of the problem?
Not being a Windows person, I'm already way beyond my knowledge of how
Windows, AD, and Kerberos interact.
Thanks for any help you can provide.
--Mike Roszkowski
University of Wisconsin-Madison
More information about the Kerberos
mailing list