Re: PAM/Kerberos issue on NetBSD

[Taylor R Campbell <riastradh () NetBSD org>]

> Date: Tue, 20 Jun 2023 17:16:58 -0700
> From: Alistair Crooks <agc () pkgsrc org>
>
> + Linux - not believed to be affected (would be good to get some
> corroboration for this)

Linux pam_krb5[1] and sssd-krb5[2] are both affected by the same
attack, but they have always been _documented_ to be affected; unlike
BSD pam_krb5, it's just not news that they are affected.

(Side note: pam_krb5 (and sssd-krb5) is not and never has been the
normal way to do Kerberos authentication in network services.  (E.g.,
in sshd, you set `GSSAPIAuthentication yes' for that.)  pam_krb5 has
always been an abuse of Kerberos as a method to check a password,
which Kerberos was designed to avoid, through SSO.)


The pam_krb5 overview[3] says:

> pam_authenticate does a complete authentication, including checking
> the resulting TGT by obtaining a service ticket for the local host
> if possible, but this requires read access to the system keytab.  If
> the keytab doesn't exist, can't be read, or doesn't include the
> appropriate credentials, the default is to accept the
> authentication.  This can be controlled by setting
> verify_ap_req_nofail to true in [libdefaults] in /etc/krb5.conf.

The pam_krb5 man page[4] says:

> If that keytab cannot be read or if no keys are found in it, the
> default (potentially insecure) behavior is to skip this check.  If
> you want to instead fail authentication if the obtained tickets
> cannot be checked, set verify_ap_req_nofail to true in the
> [libdefaults] section of /etc/krb5.conf.  Note that this will affect
> applications other than this PAM module.

The sssd-krb5 man page[5] says:

> krb5_validate (boolean)
>    Verify with the help of krb5_keytab that the TGT obtained has not
>    been spoofed.  The keytab is checked for entries sequentially,
>    and the first entry with a matching realm is used for validation.
>    If no entry matches the realm, the last entry in the keytab is
>    used.  This process can be used to validate environments using
>    cross-realm trust by placing the appropriate keytab entry as the
>    last entry or the only entry in the keytab file.
>
>    Default: false 

Exception: Oracle Linux appears to ship an mit-krb5-based Kerberos
modified to have default-secure settings instead of default-insecure,
and provides instructions for setting verify_ap_req_nofail for
insecure compatibility[6][7][8].


The verify_ap_req_nofail option rates pretty high among the
worst-named knobs I have ever seen, and has been confusing people for
decades[9][10].  I filed an issue to make it default-secure in
Heimdal[11]; this could pose compatibility issues, but sites that
continue rely on the insecure option can always set it in their
krb5.conf.


[1] https://www.eyrie.org/~eagle/software/pam-krb5/
[2] https://github.com/SSSD/sssd/tree/master/src/providers/krb5
[3] https://www.eyrie.org/~eagle/software/pam-krb5/readme.html
[4] https://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html
[5] https://linux.die.net/man/5/sssd-krb5
[6] https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html
[7] https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4
[8] https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/
[9] https://www.stacken.kth.se/lists/heimdal-discuss/2002-08/msg00001.html
[10] https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html
[11] https://github.com/heimdal/heimdal/issues/1129