Bug in 1.4.3 libkrb5, cross-realm support
Garrett Wollman
wollman at csail.mit.edu
Fri Jan 6 17:31:39 EST 2006
I recently upgraded a machine from 1.4.1 (+patches) to 1.4.3, and
found that I am no longer able to ssh into a machine that's two
cross-realm hops away. Here's a trace:
Program received signal SIGSEGV, Segmentation fault.
krb5_fcc_store_addr (context=0x554900, id=0x55eb20, addr=0x970ea711)
at cc_file.c:999
999 ret = krb5_fcc_store_ui_2(context, id, addr->addrtype);
(gdb) bt
#0 krb5_fcc_store_addr (context=0x554900, id=0x55eb20, addr=0x970ea711)
at cc_file.c:999
#1 0x0000000800d44365 in krb5_fcc_store_addrs (context=0x554900, id=0x55eb20,
addrs=0x54ac20) at cc_file.c:966
#2 0x0000000800d48bdc in krb5_fcc_store (context=0x554900, id=0x55eb20,
creds=0x553580) at cc_file.c:2151
#3 0x0000000800d4aa6b in krb5_cc_store_cred (context=0x554900,
cache=0x55eb20, creds=0x970ea711) at ccfns.c:68
#4 0x0000000800d57c07 in krb5_get_credentials (context=0x554900, options=0,
ccache=0x55eb20, in_creds=0x0, out_creds=0x7fffffffe1d0) at get_creds.c:153
#5 0x0000000800bff214 in get_credentials (context=0x554900, cred=0x553500,
server=0x56a4c0, now=1136585977, endtime=0, out_creds=0x7fffffffe1d0)
at init_sec_context.c:116
#6 0x0000000800bffbbb in new_connection (minor_status=0x549184,
cred=0x553500, context_handle=0x549188, target_name=0x549140,
mech_type=0x54a240, req_flags=34, time_req=0, input_chan_bindings=0x0,
input_token=0x0, actual_mech_type=0x0, output_token=0x7fffffffe3b0,
ret_flags=0x0, time_rec=0x0, context=0x554900, default_mech=0)
at init_sec_context.c:538
#7 0x0000000800c00740 in krb5_gss_init_sec_context (minor_status=0x549184,
claimant_cred_handle=0x0, context_handle=0x549188, target_name=0x549140,
mech_type=0x54a240, req_flags=34, time_req=0, input_chan_bindings=0x0,
input_token=0x0, actual_mech_type=0x0, output_token=0x7fffffffe3b0,
ret_flags=0x0, time_rec=0x0) at init_sec_context.c:939
---Type <return> to continue, or q <return> to quit---
#8 0x0000000800c0400c in gss_init_sec_context (minor_status=0x554900,
claimant_cred_handle=0x55eb20, context_handle=0x970ea711,
target_name=0x8011136c0, mech_type=0xffffffff8046775b,
req_flags=4294958840, time_req=5656576, input_chan_bindings=0x565000,
input_token=0x565000, actual_mech_type=0x565000, output_token=0x565000,
ret_flags=0x565000, time_rec=0x565000) at krb5_gss_glue.c:263
[remaining stack frames are in ssh]
At this point, the code has obtained the cross-realm TGTs and is
trying to store them in the credential cache, but the contents of
creds->addresses[] in frame 2 are garbage:
#1 0x0000000800d44365 in krb5_fcc_store_addrs (context=0x554900, id=0x55eb20,
addrs=0x54ac20) at cc_file.c:966
966 ret = krb5_fcc_store_addr(context, id, addrs[i]);
(gdb) p length
$9 = 16
(gdb) p *addrs at 16
$10 = {0x970ea711, 0x524500000000, 0x749415343, 0x54ac50, 0x7c0282308002826d,
0x5010203a0, 0x6e616d6c6c6f77, 0x54ac60, 0x494d2e4c49415343, 0x5544452e54,
0x495274677462726b, 0x47524f2e5954, 0x41524e4f54534f42, 0x47524f2e4f4944,
0x49524f4a414d4942, 0x47524f2e5954}
I wasn't able to follow the logic in krb5_get_cred_from_kdc()
sufficiently to tell where the bad value originates. Other than this
stray pointer, the other values in tgts[] appear to be valid.
-GAWollman
--
Garrett A. Wollman | As the Constitution endures, persons in every
wollman at csail.mit.edu | generation can invoke its principles in their own
Opinions not those | search for greater freedom.
of MIT or CSAIL. | - A. Kennedy, Lawrence v. Texas, 539 U.S. 558 (2003)
More information about the Kerberos
mailing list