Debian Patches

Status for pam-pkcs11/0.6.12-1+deb12u1

Patch Description Author Forwarded Bugs Origin Last update
1_pam.d_ignore_no_card.example add missing file from upstream Ludovic Rousseau <rousseau@debian.org> no 2023-02-04
Fixed-possible-authentication-bypass-Don-t-return-PA.patch [PATCH] Fixed possible authentication bypass: Don't return PAM_IGNORE
Starting with bac6cf8e0b242e508e8b715e7f78d52f1227840a (released with
pam_pkcs11-0.6.12), return codes defaulted to PAM_IGNORE in most cases
where authentication was not possible. This change has not been
anticipated in PAM configurations and may lead to authentication
bypasses. If pam_pkcs11 was configured as the only module which could
provide authentication and would silently fail with PAM_IGNORE, then
this return code may be transformed to PAM_SUCCESS by subsequent PAM
modules that don't actually perform authentication. This change avoids
this situation by *not* returning PAM_IGNORE by default as done in
0.6.11 and before.

If pam_pkcs11 is the only module providing authentication in the PAM
stack, then the following PAM configuration could be used to avoid this
situation as well:

auth [success=ok default=bad] pam_pkcs11.so wait_for_card card_only

In the configuration above, PAM_IGNORE will lead to an authentication
failure even for an unpatched pam_pkcs11-0.6.12 (note the missing
`ignore=ignore`).

Thanks to Matthias Gerstner (@mgerstner) and the SUSE Linux team for
reporting this problem providing analysis and the workaround
configuration of a possibly vulnerable PAM stack.		 Frank Morgner <frankmorgner@gmail.com> no 2024-12-06
fixed-possible-authentication-bypass-Use-signatures-.patch [PATCH] fixed possible authentication bypass: Use signatures to verify authentication by default

If cert_policy is set to none (the default value), then pam_pkcs11 will
only check if the user is capable of logging into the token. An attacker
may create a different token with the user's public data (e.g. the
user's certificate) and a PIN known to the attacker. If no signature
with the private key is required, then the attacker may now login as
user with that created token.

This change, by default, uses the private key to crate a signature. A
new policy, `no_signature` is introduced if the module should really
*not* validate the key's signature		 Frank Morgner <frankmorgner@gmail.com> no 2024-12-06
Update-configuration-files-for-the-CVE-2025-24032-fi.patch [PATCH] Update configuration files for the CVE-2025-24032 fix
Added a comment on the "no_signature" value. Also, use "signature"
instead of "none". Added a note, that "none" doesn't mean
"no_signature".		 Paul Wolneykien <manowar@altlinux.org> no 2025-02-04

All known versions for source package 'pam-pkcs11'

Links