Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2023 17:16:58 -0700
From: Alistair Crooks <>
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:
(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 (

My apologies for the pre-announcement not making the distros list ahead of
time, an internal miscommunication.


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:
- Oracle has the default-secure setting in their krb5 system:
- Heimdal issue on verify_ap_req_nofail default:

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.