[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2023 17:16:58 -0700
From: Alistair Crooks <agc@...src.org>
To: oss-security@...ts.openwall.com
Subject: PAM/Kerberos issue on NetBSD
Hi folks,
The fix for a pam/kerberos issue on NetBSD has already been fixed and
pullups requested for release branches, see:
https://mail-index.netbsd.org/source-changes/2023/06/20/msg145461.html
(commit log appended to this mail) and CVE-2023-3326
For various platforms, the exposure is not thought to be that great
+ Linux - not believed to be affected (would be good to get some
corroboration for this)
+ FreeBSD - affected, but not in the default install
+ OpenBSD - no kerberos
+ DragonflyBSD - no kerberos
+ NetBSD - sadly affected
This was found via code inspection by Taylor Campbell (riastradh@...BSD.org
)
My apologies for the pre-announcement not making the distros list ahead of
time, an internal miscommunication.
Regards,
agc
Module Name: src
Committed By: riastradh
Date: Tue Jun 20 22:17:18 UTC 2023
Modified Files:
src/lib/libpam/modules/pam_krb5: pam_krb5.8 pam_krb5.c
Log Message:
pam_krb5: Refuse to operate without a key to verify tickets.
New allow_kdc_spoof overrides this to restore previous behaviour
which was vulnerable to KDC spoofing, because without a host or
service key, pam_krb5 can't distinguish the legitimate KDC from a
spoofed one.
This way, having pam_krb5 enabled isn't dangerous even if you create
an empty /etc/krb5.conf to use client SSO without any host services.
Perhaps this should use krb5_verify_init_creds(3) instead, and
thereby respect the rather obscurely named krb5.conf option
verify_ap_req_nofail like the Linux pam_krb5 does, but:
- verify_ap_req_nofail is default-off (i.e., vulnerable by default),
- changing verify_ap_req_nofail to default-on would probably affect
more things and therefore be riskier,
- allow_kdc_spoof is a much clearer way to spell the idea,
- this patch is a smaller semantic change and thus less risky, and
- a security change with compatibility issues shouldn't have a
workaround that might introduce potentially worse security issues
or more compatibility issues.
Perhaps this should use krb5_verify_user(3) with secure=1 instead,
for simplicity, but it's not clear how to do that without first
prompting for the password -- which we shouldn't do at all if we
later decide we won't be able to use it anyway -- and without
repeating a bunch of the logic here anyway to pick the service name.
References about verify_ap_req_nofail:
- mit-krb5 discussion about verify_ap_req_nofail:
https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html
- Oracle has the default-secure setting in their krb5 system:
https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html
https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4
https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/
- Heimdal issue on verify_ap_req_nofail default:
https://github.com/heimdal/heimdal/issues/1129
To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.13 src/lib/libpam/modules/pam_krb5/pam_krb5.8
cvs rdiff -u -r1.30 -r1.31 src/lib/libpam/modules/pam_krb5/pam_krb5.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
