Bug in 1.4.3 libkrb5, cross-realm support

[Garrett Wollman]

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)