N**BSD-SA2023-006 KDC-spoofing in pam_krb5

Takehiko NOZAKI reporter

changed status to resolved

BUGFIX: Issue ~~#365~~ - N**BSD-SA2023-006 KDC-spoofing in pam_krb5 see https://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2023-006.txt.asc

patches are derived from:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.c.diff?r1=1.30&r2=1.31
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.8.diff?r1=1.12&r2=1.13 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
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.c.diff?r1=1.31&r2=1.32 pam_krb5: Fix PR lib/57631.

Loose ends in the fix for NetBSD-SA2023-006 that weren't caught by review or, somehow, by my own testing. Evidently we need automatic tests for this pam business.

XXX pullup-10 XXX pullup-9 XXX pullup-8

→ <<cset b8594f5cf0cd>>

2023-12-18T08:48:25+00:00

Comments (2)

Takehiko NOZAKI reporter
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.c.diff?r1=1.30&r2=1.32
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.8.diff?r1=1.12&r2=1.13
- 2023-12-17T07:12:28+00:00
Takehiko NOZAKI reporter
- changed status to resolved
BUGFIX: Issue ~~#365~~ - N**BSD-SA2023-006 KDC-spoofing in pam_krb5 see https://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2023-006.txt.asc

patches are derived from:
- http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.c.diff?r1=1.30&r2=1.31
- http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.8.diff?r1=1.12&r2=1.13 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
- http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpam/modules/pam_krb5/pam_krb5.c.diff?r1=1.31&r2=1.32 pam_krb5: Fix PR lib/57631.
  
  Loose ends in the fix for NetBSD-SA2023-006 that weren't caught by review or, somehow, by my own testing. Evidently we need automatic tests for this pam business.
  
  XXX pullup-10 XXX pullup-9 XXX pullup-8
→ <<cset b8594f5cf0cd>>
- 2023-12-18T08:48:25+00:00
Log in to comment