Assigning to Andreas for his follow-up.

This looks like a DoS in the AD DC KDC (when built with the MIT Kerberos).

This is more or less the same issue as:

https://git.samba.org/?p=asn/samba.git;a=commitdiff;h=d47d74998c4adaa32515c361ed3033eb2bd78f4a

In the KDB API we miss still information e.g. if the request is a FAST request or not.

Hi Andreas,

It doesn't look related to FAST as the domain member I'm running the s4u2self request from, is build with embedded heimdal which does not do FAST afaict.

And it's not 'krb5_db_entry *client' that's NULL in s4u2self, it's 'kdcreq->client'.

The below diff prevents the crash.

diff --git a/source4/kdc/mit-kdb/kdb_samba_policies.c b/source4/kdc/mit-kdb/kdb_samba_policies.c
index de5813bde2f..1da94540b31 100644
--- a/source4/kdc/mit-kdb/kdb_samba_policies.c
+++ b/source4/kdc/mit-kdb/kdb_samba_policies.c
@@ -90,6 +90,10 @@ krb5_error_code kdb_samba_db_check_policy_as(krb5_context context,
                return KRB5_KDB_DBNOTINITED;
        }

+       if (kdcreq->client == NULL) {
+               return KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN;
+       }
+
        if (ks_is_kadmin(context, kdcreq->client)) {
                return KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN;
        }

Created attachment 14431 [details]
possible patch

In a closer look, it seems that 'kdcreq->client' is NULL in this case because it's a TGS which doesn't parse the client principal, and S4U2Self is the only case we get here in TGS flow.
I think the attached patch should be ok.

btw, I found an easy way to reproduce on the DC machine it self (without the net-ads-kerberos-pac fixes for DC), using kvno.

e.g.
# acquire machine creds
net -P ads kerberos kinit
# try protocol transition
kvno -UAdministrator@REALM machine\$@REALM

And then check that the kdc is still up and running (s4u2self still fails for now).
I'll try to make a test out of it.

Created attachment 14432 [details]
blackbox test

a tester using kvno.

Andreas,

Do you plan to address this before Samba 4.9?

Thanks,

Andrew Bartlett

Created attachment 14451 [details]
patch for master

(In reply to Andreas Schneider from comment #9)
Andreas,

Can you please prepare the security patches for this, and do the CVE etc?

Thanks,

Andrew Bartlett

Hi Andreas, all,

I got another crash, with both our patches applied (or without).
Not sure if how i missed it before, or perhaps something changed elsewhere to cause it now.

I'm testing current master branch of both samba and mit-krb5 library.

# ./configure --enable-debug --enable-selftest --with-system-mitkrb5 /usr/local --with-system-mitkdc=/usr/local/sbin/krb5kdc

# make -j4 && sudo make install

Then I get the crash when running the below test:
# make test TESTS=samba4.blackbox.kinit FAIL_IMMEDIATELY=1 SAMBA_OPTIONS="-d3"
...
samba_runcmd_io_handler: Child /usr/local/sbin/krb5kdc exited 11
The MIT KDC daemon died with exit status 11
...

# coredumpctl gdb
...

Core was generated by `/usr/local/sbin/krb5kdc -n'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  load_uint (size=4, val=0x7f003bce72d7) at asn1_encode.c:504
504         case 4: return *(uint32_t *)val;
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.26-24.fc27.x86_64 gpgme-1.9.0-6.fc27.x86_64 libassuan-2.5.1-1.fc27.x86_64 libcrypt-nss-2.26-24.fc27.x86_64 libgcc-7.3.1-2.fc27.x86_64 lmdb-libs-0.9.22-1.fc27.x86_64 nss-3.34.0-1.0.fc27.x86_64 nss-softokn-freebl-3.34.0-1.0.fc27.x86_64 nss-util-3.34.0-1.0.fc27.x86_64 pcre2-10.31-3.fc27.x86_64 systemd-libs-234-9.fc27.x86_64
(gdb) bt
#0  load_uint (size=4, val=0x7f003bce72d7) at asn1_encode.c:504
#1  load_count (val=val@entry=0x7f003bce72cf, counted=counted@entry=0x7f3e3e7fafa0 <aux_info_pa_data_2_untagged>, count_out=count_out@entry=0x7ffcf0d4b7a8)
    at asn1_encode.c:523
#2  0x00007f3e3e550419 in encode_atype (buf=buf@entry=0x7ffcf0d4bad0, val=val@entry=0x7f003bce72cf, a=<optimized out>, tag_out=tag_out@entry=0x7ffcf0d4b890)
    at asn1_encode.c:704
#3  0x00007f3e3e550597 in encode_atype (buf=buf@entry=0x7ffcf0d4bad0, val=val@entry=0x7f003bce72cf, a=<optimized out>, tag_out=tag_out@entry=0x7ffcf0d4b890)
    at asn1_encode.c:724
#4  0x00007f3e3e550a2a in encode_atype_and_tag (buf=buf@entry=0x7ffcf0d4bad0, val=val@entry=0x7f003bce72cf, a=<optimized out>) at asn1_encode.c:779
#5  0x00007f3e3e5504ca in encode_sequence (seq=0x7f3e3e7f63e0 <aux_seqinfo_pa_data>, val=0x7f003bce72cf, buf=0x7ffcf0d4bad0) at asn1_encode.c:849
#6  encode_atype (buf=buf@entry=0x7ffcf0d4bad0, val=0x7f003bce72cf, a=a@entry=0x7f3e3e7f63c0 <k5_atype_pa_data>, tag_out=tag_out@entry=0x7ffcf0d4b9d0)
    at asn1_encode.c:673
#7  0x00007f3e3e550373 in encode_atype (buf=buf@entry=0x7ffcf0d4bad0, val=0x7ffcf0d4bb78, a=a@entry=0x7f3e3e7f63a0 <k5_atype_pa_data_ptr>,
    tag_out=tag_out@entry=0x7ffcf0d4b9d0) at asn1_encode.c:683
#8  0x00007f3e3e550a2a in encode_atype_and_tag (buf=buf@entry=0x7ffcf0d4bad0, val=<optimized out>, a=a@entry=0x7f3e3e7f63a0 <k5_atype_pa_data_ptr>)
    at asn1_encode.c:779
#9  0x00007f3e3e55056a in encode_sequence_of (eltinfo=0x7f3e3e7f63a0 <k5_atype_pa_data_ptr>, val=0x7ffcf0d4bb38, seqlen=<optimized out>, buf=0x7ffcf0d4bad0)
    at asn1_encode.c:869
#10 encode_nullterm_sequence_of (can_be_empty=<optimized out>, type=0x7f3e3e7f63a0 <k5_atype_pa_data_ptr>, val=0x7ffcf0d4bb38, buf=0x7ffcf0d4bad0)
    at asn1_encode.c:483
#11 encode_atype (buf=buf@entry=0x7ffcf0d4bad0, val=val@entry=0x7ffcf0d4bb38, a=a@entry=0x7f3e3e7faf30 <k5_atype_seqof_pa_data>,
    tag_out=tag_out@entry=0x7ffcf0d4ba90) at asn1_encode.c:712
#12 0x00007f3e3e550a2a in encode_atype_and_tag (buf=buf@entry=0x7ffcf0d4bad0, val=val@entry=0x7ffcf0d4bb38,
    a=a@entry=0x7f3e3e7faf30 <k5_atype_seqof_pa_data>) at asn1_encode.c:779
#13 0x00007f3e3e551c39 in k5_asn1_full_encode (rep=0x7ffcf0d4bb38, a=0x7f3e3e7faf30 <k5_atype_seqof_pa_data>, code_out=0x7ffcf0d4bb30) at asn1_encode.c:1545
#14 0x00007f3e3bce4562 in samba_kdc_build_edata_reply (nt_status=..., e_data=0x7ffcf0d4bc30) at ../source4/kdc/mit_samba.c:891
#15 0x00007f3e3bce463f in mit_samba_check_client_access (ctx=0xcebae0, client=0x7ffcf0d4bce0, client_name=0x1b0ea00 "nettestuser@SAMBA.EXAMPLE.COM",
    server=0x7ffcf0d4bd38, server_name=0x175e650 "krbtgt/SAMBA.EXAMPLE.COM@SAMBA.EXAMPLE.COM", netbios_name=0x0, password_change=false,
    e_data=0x7ffcf0d4bc30) at ../source4/kdc/mit_samba.c:930
#16 0x00007f3e3bce57f5 in kdb_samba_db_check_policy_as (context=0xc93d00, kdcreq=0x1606fa0, client=0x7ffcf0d4bce0, server=0x7ffcf0d4bd38,
    kdc_time=1537342946, status=0x1178420, e_data_out=0x1178428) at ../source4/kdc/mit-kdb/kdb_samba_policies.c:130
#17 0x000000000040d1c5 in validate_as_request (kdc_active_realm=kdc_active_realm@entry=0xc93c60, request=0x1606fa0, client=..., server=...,
    kdc_time=1537342946, status=status@entry=0x1178420, e_data=e_data@entry=0x1178428) at kdc_util.c:747
#18 0x0000000000408807 in process_as_req (request=0x1606fa0, req_pkt=<optimized out>, local_addr=0x1fa40a8, remote_addr=0x1fa4080,
    kdc_active_realm=0xc93c60, vctx=0xd5cba0, respond=0x4071f0 <finish_dispatch_cache>, arg=0xdc6810) at do_as_req.c:671
#19 0x0000000000407511 in dispatch (cb=0x620a90 <shandle>, local_addr=local_addr@entry=0x1fa40a8, remote_addr=remote_addr@entry=0x1fa4080,
    pkt=pkt@entry=0x1fa41c8, is_tcp=is_tcp@entry=0, vctx=vctx@entry=0xd5cba0, respond=0x4176c0 <process_packet_response>, arg=0x1fa4050) at dispatch.c:201
#20 0x0000000000419499 in process_packet (ctx=0xd5cba0, ev=<optimized out>) at net-server.c:1086
#21 0x00007f3e3d6afec3 in verto_fire (ev=0xd6ef80) at verto.c:1006
#22 0x00007f3e3d6b58d0 in libev_callback (loop=0x7f3e3d8b9300 <default_loop_struct>, w=0xd65a70, revents=1) at verto-k5ev.c:133
#23 0x00007f3e3d6b37e6 in k5ev_invoke_pending (loop=0x7f3e3d8b9300 <default_loop_struct>) at ev.c:3295
#24 0x00007f3e3d6b3ffb in k5ev_run (loop=0x7f3e3d8b9300 <default_loop_struct>, flags=0) at ev.c:3695
#25 0x00007f3e3d6b57dc in k5ev_ctx_run (ctx=0x7f3e3d8b9300 <default_loop_struct>) at verto-k5ev.c:91
#26 0x00007f3e3d6af104 in verto_run (ctx=0xd5cba0) at verto.c:630
#27 0x000000000040650b in main (argc=2, argv=0x7ffcf0d4c238) at main.c:1050


Can you reproduce this? the crash looks a bit complicated.

Regards.

For the upcoming security release, should we just announce that the MIT KDC is not security-supported, so we can open this up as a public bug and deal with it as resources permit?

The current situation here really isn't ideal, particularly as some of these issues have been known in public patches for quite some time.

(In reply to Andrew Bartlett from comment #12)
Specifically, the patch in comment #3 is both public and dated Sep 2016 and March 2018.  We shouldn't maintain the fiction of an embargo here.

Isaac,

Are you OK if I list you as the reporter in the credits for the advisory on this one?

I'm preparing an advisory to say that we won't be issuing patches, and pointing users here for further updates.

Thanks,

Andrew Bartlett

(In reply to Andrew Bartlett from comment #14)

Yes please, I'd be happy to be credited, thank you.

Also, sorry for over complicating it with the other asn1 crash, should have opened a new bug (it confused me how the test passed initially, I think I might have used kinit_trust test at first, which passes ok).
Anyway, I'll take another look at that crash too.

Created attachment 14626 [details]
fix asn1 crash

#10 encode_nullterm_sequence_of (can_be_empty=<optimized out>, type=0x7f15b30acb40 <k5_atype_pa_data_ptr>, val=0x7ffc03acf228, buf=0x7ffc03acf1c0)
    at asn1_encode.c:483
...
#13 0x00007f15b2e07b59 in k5_asn1_full_encode (rep=0x7ffc03acf228, a=0x7f15b30b1f00 <k5_atype_seqof_pa_data>, code_out=0x7ffc03acf220) at asn1_encode.c:1545
#14 0x00007f15b0902562 in samba_kdc_build_edata_reply (nt_status=..., e_data=0x7ffc03acf320) at ../source4/kdc/mit_samba.c:891

The encode_krb5_padata_sequence() macro (wrapper to k5_asn1_full_encode) seem to expect a null terminated array.

Attached patch fixes the asn1 crash, and with it samba4.blackbox.kinit test passes ok.

Please take a look.

Looks fine for me, I set review+ for it.

Created attachment 14676 [details]
patch for master

Created attachment 14677 [details]
patch for 4.9

Created attachment 14678 [details]
patch for 4.8

Created attachment 14679 [details]
patch for 4.7

Pushed to autobuild-v4-{8,9}-test and picked locally for v4-7-stable.

Pushed to both branches.
Closing out bug report.

Thanks!