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 <bugs@mlmmj.nyi.freebsd.org>; 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 <bugs@FreeBSD.org>; 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 <bugs@FreeBSD.org>; 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 <bugs@FreeBSD.org>; 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: <bug-268149-227@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-bugs.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-bugs
List-Help: <mailto:freebsd-bugs+help@freebsd.org>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Subscribe: <mailto:freebsd-bugs+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-bugs+unsubscribe@freebsd.org>
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<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.=