NetBSD Problem Report #57470

From www@netbsd.org  Thu Jun 15 13:43:24 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4E0BE1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 15 Jun 2023 13:43:24 +0000 (UTC)
Message-Id: <20230615134322.A686F1A923D@mollari.NetBSD.org>
Date: Thu, 15 Jun 2023 13:43:22 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: su hangs on network access via pam_ksu even if it will never succeed
X-Send-Pr-Version: www-1.0

>Number:         57470
>Category:       bin
>Synopsis:       su hangs on network access via pam_ksu even if it will never succeed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 15 13:45:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        netbsd-9
>Organization:
The KnetBSD Foundation
>Environment:
>Description:
/etc/pam.d/su has pam_ksu enabled by default.

If ~/.krb5/config exists (in the home directory of the user running su, not the user they're switching to), or if /etc/krb5.conf exists, then pam_ksu will get past krb5_init_context.

If there's no /root/.k5login or if the host has no keytab, pam_ksu will never succeed, because it uses krb5_verify_init_creds with the ap_req_nofail option.

But it doesn't discover this until it has done two other things first:

1. Find a default realm.  If it's not specified in the krb5 config, this will happen by default through DNS lookup of _kerberos TXT records based on the system hostname.
2. Find a KDC for the realm.  If it's not specified in the krb5 config, this will happen by default through DNS lookup of _kerberos._tcp/_udp SRV records based on the realm.

I don't think there's any security vulnerability here, or much of a privacy leak, because the next thing it will do is discover that /root/.k5login doesn't exist, and as long as the user's name isn't already root, that puts an end to it.
>How-To-Repeat:
turn off the network

$ touch ~/.krb5/config
$ su
>Fix:
Yes, please!

pam_ksu should:

1. check for /root/.k5login early -- if it's not there, fail
2. check for any keytab early -- if there's no keytab, fail

That way, it is safe to create ~/.krb5/config or /etc/krb5.conf without causing weird unrelated things to fail.

Home	PR Database Search