Date: Sun, 04 Dec 2022 16:16:18 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 268149] kadmind handle_mit() rpc/gss bugs Message-ID: <bug-268149-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268149 Bug ID: 268149 Summary: kadmind handle_mit() rpc/gss bugs Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: rtm@lcs.mit.edu Attachment #238511 text/plain mime type: Created attachment 238511 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D238511&action= =3Dedit tickle bugs in kadmind's RPC/GSS interface by sending RPCs in the clear The heimdal kadmind has code to receive requests via ONC RPC protected by GSS encryption and signatures; this is handle_mit() etc in kadmind/rpc.c. One problem is that kadmind reads RPC arguments in the clear direct from the TCP connection, with no encryption or signature (and not preceded by a length). This means that an eavesdropper could read or modify RPC arguments (including, I believe, the passwords in create requests). That is, when receiving an RPC on a connection that's already been set up and had initial authentication done, process_stream(...,sp) in kadmind/rpc.c does this: read an RPC length from sp (which is just the socket, no crypto yet); read_data(sp, msg, len); // copy bytes from sp socket to msg buffer parse the RPC header, including cred and verf, out of msg; case RPC_DATA: gss_unwrap(... &gout ...) which I believe decrypts, and checks the signature (*procs[chdr.proc].func)(server_handle, sp, dreply); Note that the 2nd argument to procs[].func is sp, not gout or sp1. That is, the RPC handler function is going to read its arguments in clear-text from the underlying socket, not from a data buffer that is the result of decryption and signature check. Separately, after the RPC handler has returned, process_stream()=20 frees sp but then uses it to send the reply: krb5_storage_free(sp); ... much later; CHECK(krb5_store_uint32(sp, data.length | LAST_FRAGMENT)); sret =3D krb5_storage_write(sp, data.data, data.length); This potentially results in reading and writing and calling through garbage pointers. Separately, there are a couple of calls to ret_string_xdr() and ret_principal_xdr() that assume that if these fuctions return zero (success), then they allocated a string. That's not the case: if the client specified a zero-length string, these functions set the string pointer to NULL. I've attached a demo. Due to some error in my setup, the host name must be set to "admin" in order for this to work; otherwise the gss rpc library changes "kadmin/admin" to "kadmind\\/admin", which kdc doesn't recognize. valgrind or a debugging malloc is required to see the use-after-free. kinit is required. # cc kadmind27a.c -lrpcsec_gss # hostname admin # kinit # valgrind /usr/libexec/kadmind --debug & # ./a.out If the user has no kadmind permissions, I get the use-after-free bug: #0 0x00000f24b3546b31 in krb5_store_int (sp=3D0xf24bb6d6180,=20 value=3D<optimized out>, len=3D4) at /usr/src/crypto/heimdal/lib/krb5/store.c:328 #1 krb5_store_int32 (sp=3D0xf24bb6d6180, value=3D<optimized out>) at /usr/src/crypto/heimdal/lib/krb5/store.c:356 #2 krb5_store_uint32 (sp=3Dsp@entry=3D0xf24bb6d6180, value=3D<optimized ou= t>) at /usr/src/crypto/heimdal/lib/krb5/store.c:375 #3 0x00000f1c8fc8d07d in process_stream (contextp=3D0xf24bb6d7000,=20 buf=3D0xf24b0753974 "$\017", ilen=3D0, sp=3D0xf24bb6d6180) at /usr/src/crypto/heimdal/kadmin/rpc.c:1087 #4 handle_mit (contextp=3Dcontextp@entry=3D0xf24bb6d7000,=20 buf=3Dbuf@entry=3D0xf24b0753970, len=3Dlen@entry=3D4, sock=3D<optimized= out>) at /usr/src/crypto/heimdal/kadmin/rpc.c:1107 #5 0x00000f1c8fc8e46a in kadmind_loop (contextp=3D0xf24bb6d7000,=20 keytab=3D0xf24bb6eb000, sock=3D-1) at /usr/src/crypto/heimdal/kadmin/server.c:591 #6 0x00000f1c8fc8fae9 in main (argc=3D<optimized out>, argv=3D<optimized o= ut>) at /usr/src/crypto/heimdal/kadmin/kadmind.c:202 If the user has kadmind permissions, kadmind crashes when trying to use a NULL principal name: #0 _hdb_fetch_kvno (context=3D0x6972dc59000, db=3D0x6972dc74000, principal= =3D0x0,=20 flags=3D93, kvno=3D0, entry=3D0x6971fd5d880) at /usr/src/crypto/heimdal/lib/hdb/common.c:110 #1 0x0000069721cadb81 in kadm5_s_delete_principal ( server_handle=3D0x6972dc5a040, princ=3D0x0) at /usr/src/crypto/heimdal/lib/kadm5/delete_s.c:51 #2 0x0000068efeee0140 in proc_delete_principal (contextp=3D0x6972dc5a040,= =20 in=3D<optimized out>, out=3D0x6972dc58200) at /usr/src/crypto/heimdal/kadmin/rpc.c:597 #3 0x0000068efeee1d15 in process_stream (contextp=3D0x6972dc59000,=20 buf=3D0x6971fd5dd14 "\227\006", ilen=3D0, sp=3D0x6972dc58180) at /usr/src/crypto/heimdal/kadmin/rpc.c:926 #4 handle_mit (contextp=3Dcontextp@entry=3D0x6972dc59000,=20 buf=3Dbuf@entry=3D0x6971fd5dd10, len=3Dlen@entry=3D4, sock=3D<optimized= out>) at /usr/src/crypto/heimdal/kadmin/rpc.c:1107 #5 0x0000068efeee346a in kadmind_loop (contextp=3D0x6972dc59000,=20 keytab=3D0x6972dc6d000, sock=3D93) at /usr/src/crypto/heimdal/kadmin/server.c:591 #6 0x0000068efeee4ae9 in main (argc=3D<optimized out>, argv=3D<optimized o= ut>) at /usr/src/crypto/heimdal/kadmin/kadmind.c:202 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268149-227>