From nobody Sun Dec 4 16:16:18 2022 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NQBcz3lQMz4jcss for ; Sun, 4 Dec 2022 16:16:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NQBcz059Wz4MWn for ; Sun, 4 Dec 2022 16:16:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670170579; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=BKWdN5RHJBRVDEFS1x/aeVnW4D6012IK9f8j/2uYGjE=; b=edauBcp+3cayLqcR7DuAaNbKIWVkO+lPMjmywqxem938nRidPFHMbhrFMxvXBQMM40o6N+ YDIj8hHM0Xd+VrTbn8Bo4Qjnlgp+Vrli2LdyXb8BOdg9yvckMHlgWWgIgTseA50Ex7mX27 VZc9eQTSmmRelgGAVro5/IgyVHQAy0WRR0FB5kKI2K+AOfShjBgv/JMIKX8b+/aBfxhBsi ht+6a8zajDuDGc23gNFxQhBPE0TuR7D/JscuaFfvkEGfHwLxVuopdDf9EIZip7hSQ7RnVb QzL2yHTHTdZGWDHk/0phgeQkNa250hXGlWIt9XctPHFR41KMkJcLVTGFR3LEyw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670170579; a=rsa-sha256; cv=none; b=jaQNnyGUbr+0/Argf/oMm3+hh7dyJ63ji+ePv/lzh2nIWvPDkYTHUMqgmy/XcXlgtq1V9M UbUI9MsWQ9MdPNnCyDFqOP1Jhk+7kbf2dsRgRN3QhbZIcSKO+PxBj2VezvOnx+KNLB2qB2 YP73orLL6zlnfRWPQSlD8syRCNIFjIJGuj+eBsFguGmvreeBzN0HC2R98Jp9SpRgSw2oNl m5ZJxF3y2b6iG9YJk7cJfhrkl3ustQHXq20kEQ9EdjScDA62MhZgrLU6o0CuRwt7yhXgHy GOxHRaocz/XTiveRtKLtZATEp+b9jWe/AZGQsPSwjHBgqq9Ue64vXwOWk6FnNw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4NQBcy6FKNzQ38 for ; Sun, 4 Dec 2022 16:16:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 2B4GGIiQ012256 for ; Sun, 4 Dec 2022 16:16:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2B4GGIVZ012255 for bugs@FreeBSD.org; Sun, 4 Dec 2022 16:16:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 268149] kadmind handle_mit() rpc/gss bugs Date: Sun, 04 Dec 2022 16:16:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rtm@lcs.mit.edu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.mimetype attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N 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, len=3D4) at /usr/src/crypto/heimdal/lib/krb5/store.c:328 #1 krb5_store_int32 (sp=3D0xf24bb6d6180, value=3D) at /usr/src/crypto/heimdal/lib/krb5/store.c:356 #2 krb5_store_uint32 (sp=3Dsp@entry=3D0xf24bb6d6180, value=3D) 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) 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, argv=3D) 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, 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) 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, argv=3D) at /usr/src/crypto/heimdal/kadmin/kadmind.c:202 --=20 You are receiving this mail because: You are the assignee for the bug.=