Bug 13571 - (CVE-2018-16853) [SECURITY] CVE-2018-16853 S4U2Self crash with MIT KDC build
(CVE-2018-16853)
[SECURITY] CVE-2018-16853 S4U2Self crash with MIT KDC build
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
unspecified
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-13 22:53 UTC by Isaac Boukris
Modified: 2018-12-05 08:43 UTC (History)
6 users (show)

See Also:


Attachments
possible patch (1.66 KB, patch)
2018-08-17 22:22 UTC, Isaac Boukris
no flags Details
blackbox test (2.86 KB, patch)
2018-08-18 13:16 UTC, Isaac Boukris
no flags Details
patch for master (6.24 KB, patch)
2018-08-28 12:38 UTC, Andreas Schneider
no flags Details
fix asn1 crash (1.31 KB, patch)
2018-11-07 21:15 UTC, Isaac Boukris
asn: review+
Details
patch for master (8.01 KB, patch)
2018-11-21 12:30 UTC, Andreas Schneider
metze: review+
Details
patch for 4.9 (8.01 KB, patch)
2018-11-21 12:40 UTC, Andreas Schneider
metze: review+
Details
patch for 4.8 (8.01 KB, patch)
2018-11-21 12:40 UTC, Andreas Schneider
metze: review+
Details
patch for 4.7 (7.55 KB, patch)
2018-11-21 12:40 UTC, Andreas Schneider
metze: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Isaac Boukris 2018-08-13 22:53:09 UTC
See initial report:
https://lists.samba.org/archive/samba-technical/2018-August/129670.html

When trying a s4u2self request against a fresh samba AD built with MIT krb5, the kdc segfaults, see traces below.

To reproduce you'd need a domain member (since net-ads-kerberos is currently broken on DC), and to run:
net ads kerberos pac dump impersonate=administrator@REALM -P -d3

I'm not sure if the bug is the library for sending 'kdcreq->client' as
NULL, any idea?
But anyway we should probably add a check for it in
kdb_samba_db_check_policy_as() so we don't crash.


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5bffab7 in ks_is_kadmin (context=0x647620, princ=0x0) at ../source4/kdc/mit-kdb/kdb_samba_common.c:76
76              return krb5_princ_size(context, princ) >= 1 &&
(gdb) bt
#0  0x00007ffff5bffab7 in ks_is_kadmin (context=0x647620, princ=0x0) at ../source4/kdc/mit-kdb/kdb_samba_common.c:76
#1  0x00007ffff5c00179 in kdb_samba_db_check_policy_as (context=0x647620, kdcreq=0x137d020, client=0x7fffffffdc30, server=0x7fffffffdc88,
    kdc_time=1534188443, status=0x7fffffffde88, e_data_out=0x7fffffffdd10) at ../source4/kdc/mit-kdb/kdb_samba_policies.c:93
#2  0x000000000040d005 in validate_as_request (kdc_active_realm=kdc_active_realm@entry=0x646d70, request=request@entry=0x137d020, client=..., server=...,
    kdc_time=kdc_time@entry=1534188443, status=status@entry=0x7fffffffde88, e_data=e_data@entry=0x7fffffffdd10) at kdc_util.c:747
#3  0x000000000040e674 in kdc_process_s4u2self_req (kdc_active_realm=kdc_active_realm@entry=0x646d70, request=0x137d020, client_princ=0xe07a80,
    server=<optimized out>, tgs_subkey=<optimized out>, tgs_session=<optimized out>, kdc_time=1534188443, s4u_x509_user=0x7fffffffdeb0,
    princ_ptr=0x7fffffffde90, status=0x7fffffffde88) at kdc_util.c:1567
#4  0x0000000000409c08 in process_tgs_req (request=<optimized out>, pkt=pkt@entry=0x16ace90, from=from@entry=0xdfef40, kdc_active_realm=0x646d70,
    response=response@entry=0x7fffffffe148) at do_tgs_req.c:269
#5  0x0000000000407396 in dispatch (cb=0x620a30 <shandle>, local_addr=local_addr@entry=0x16ace78, remote_addr=remote_addr@entry=0xdfef40,
    pkt=pkt@entry=0x16ace90, is_tcp=is_tcp@entry=1, vctx=vctx@entry=0x69e4f0, respond=0x417440 <process_tcp_response>, arg=0x16acde0) at dispatch.c:196
#6  0x0000000000419151 in process_tcp_connection_read (ctx=0x69e4f0, ev=0xcdec90) at net-server.c:1349
#7  0x00007ffff6409a68 in verto_fire () from /lib64/libverto.so.1
#8  0x00007fffdc14e293 in ev_invoke_pending () from /lib64/libev.so.4
#9  0x00007fffdc151859 in ev_run () from /lib64/libev.so.4
#10 0x000000000040634b in main (argc=2, argv=0x7fffffffe498) at main.c:1050
Comment 1 Andrew Bartlett 2018-08-14 00:01:36 UTC
Assigning to Andreas for his follow-up.
Comment 2 Andrew Bartlett 2018-08-14 00:05:01 UTC
This looks like a DoS in the AD DC KDC (when built with the MIT Kerberos).
Comment 3 Andreas Schneider 2018-08-14 06:38:49 UTC
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.
Comment 4 Isaac Boukris 2018-08-14 09:42:36 UTC
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;
        }
Comment 5 Isaac Boukris 2018-08-17 22:22:59 UTC
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.
Comment 6 Isaac Boukris 2018-08-18 01:12:14 UTC
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.
Comment 7 Isaac Boukris 2018-08-18 13:16:55 UTC
Created attachment 14432 [details]
blackbox test

a tester using kvno.
Comment 8 Andrew Bartlett 2018-08-21 22:08:44 UTC
Andreas,

Do you plan to address this before Samba 4.9?

Thanks,

Andrew Bartlett
Comment 9 Andreas Schneider 2018-08-28 12:38:30 UTC
Created attachment 14451 [details]
patch for master
Comment 10 Andrew Bartlett 2018-09-12 13:14:07 UTC
(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
Comment 11 Isaac Boukris 2018-09-19 07:47:02 UTC
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.
Comment 12 Andrew Bartlett 2018-11-05 22:07:49 UTC
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.
Comment 13 Andrew Bartlett 2018-11-05 22:11:02 UTC
(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.
Comment 14 Andrew Bartlett 2018-11-06 21:02:03 UTC
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
Comment 15 Isaac Boukris 2018-11-07 07:15:17 UTC
(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.
Comment 16 Isaac Boukris 2018-11-07 21:15:55 UTC
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.
Comment 17 Andreas Schneider 2018-11-08 07:12:57 UTC
Looks fine for me, I set review+ for it.
Comment 18 Andreas Schneider 2018-11-21 12:30:28 UTC
Created attachment 14676 [details]
patch for master
Comment 19 Andreas Schneider 2018-11-21 12:40:09 UTC
Created attachment 14677 [details]
patch for 4.9
Comment 20 Andreas Schneider 2018-11-21 12:40:36 UTC
Created attachment 14678 [details]
patch for 4.8
Comment 21 Andreas Schneider 2018-11-21 12:40:59 UTC
Created attachment 14679 [details]
patch for 4.7
Comment 22 Karolin Seeger 2018-12-04 12:22:02 UTC
Pushed to autobuild-v4-{8,9}-test and picked locally for v4-7-stable.
Comment 23 Karolin Seeger 2018-12-05 08:43:24 UTC
Pushed to both branches.
Closing out bug report.

Thanks!