1.8.2 KDCs segfaulting on authdata processing

Greg Hudson ghudson at MIT.EDU
Thu Sep 2 14:26:42 EDT 2010


Sorry it's taken so long to get back to you on this.  I'm moving
discussion to a closed list (plus you, of course) since KDC crashes
generally indicate a security issue.

All processing of enc_tkt_reply->authorization_data goes through
merge_authdata().  If you had a way of generating a request which caused
a crash, you could set a breakpoint on merge_authdata and check the
authdata array after each time.

But it doesn't sound like you have that ability, so I think what you
want to do is induce the crash to happen at the time the authdata array
becomes invalid.  I'd suggest the following temporary code modification:

Index: kdc_authdata.c
===================================================================
--- kdc_authdata.c	(revision 24286)
+++ kdc_authdata.c	(working copy)
@@ -502,8 +502,9 @@
         return 0;
 
     if (authdata != NULL) {
-        for (nadata = 0; authdata[nadata] != NULL; nadata++)
-            ;
+        for (nadata = 0; authdata[nadata] != NULL; nadata++) {
+            krb5_authdatatype t = authdata[nadata]->ad_type;
+        }
     }
 
     for (i = 0; in_authdata[i] != NULL; i++)
@@ -548,6 +549,9 @@
     }
 
     *out_authdata = authdata;
+    for (i = 0; authdata[i]; i++) {
+        krb5_authdatatype t = authdata[i]->ad_type;
+    }
 
     return 0;
 }

The first hunk should detect if the input authdata contains invalid
pointers; the second hunk should verify that the resulting authdata
array acontains valid pointers.  You may need to compile with
optimization turned off (configure with CFLAGS=-g) to make sure those
dereferences don't get optimized out.

On Fri, 2010-08-27 at 14:08 -0400, Mike Roszkowski wrote:
> 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
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos





More information about the Kerberos mailing list