Update to libpam_u2f-1.3.1 has broken PAM functionality for Yubikey 5

[mitsukuri]

What version of pam-u2f are you using?

libpam-u2f (1.3.1-1~ppa3~jammy1) as per /var/log/apt/term.log

Obtained it with today's routine apt update

What operating system are you using?

Ubuntu 22.04.5

libfido2-1/jammy,now 1.15.0~ppa~jammy1 amd64

What authenticator are you using?

Yubikey 5c nano

fido2-token -I:

proto: 0x02
major: 0x05
minor: 0x04
build: 0x03
caps: 0x05 (wink, cbor, msg)
version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE
extension strings: credProtect, hmac-secret
transport strings: usb
algorithms: es256 (public-key), eddsa (public-key)
aaguid: *redacted*
options: rk, up, noplat, clientPin, credentialMgmtPreview
fwversion: 0x50403
maxmsgsiz: 1200
maxcredcntlst: 8
maxcredlen: 128
maxcredblob: 0
maxlargeblob: 0
minpinlen: 4
pin protocols: 2, 1
pin retries: 8
pin change required: false
uv retries: undefined

Problem description

After today's routine software update I'm unable to log in and sudo using my Yubikey as 2nd factor auth. I was asked for my password, and then I expected to see the prompt to touch the authenticator, which failed to display. The login form hanged and didn't respond.

I had to enter recovery console and comment out all @include common-yubikey lines from /etc/pam.d/sudo, /etc/pam.d/login and other Yubikey-enabled entries, where common-yubikey file looks like this:

auth required pam_u2f.so cue [cue_prompt=Tap...] authfile=/etc/yubico/u2f_keys

I'd like to emphasize the fact that it all worked fine before the update. FIDO2 web auth still works alright, I was able to log in to GitHub with my Yubikey.

Here's my /etc/pam.d/login:

#%PAM-1.0
auth       optional   pam_faildelay.so  delay=3000000
auth       requisite  pam_nologin.so
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session    required     pam_loginuid.so
session    optional   pam_motd.so motd=/run/motd.dynamic
session    optional   pam_motd.so noupdate
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session       required   pam_env.so readenv=1
session       required   pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
# @include common-yubikey <-- HAD TO COMMENT THIS OUT
auth       optional   pam_group.so
session    required   pam_limits.so
session    optional   pam_lastlog.so
session    optional   pam_mail.so standard
session    optional   pam_keyinit.so force revoke
@include common-account
@include common-session
@include common-password

/etc/pam.d/gdm-password:

#%PAM-1.0
auth    requisite       pam_nologin.so
auth	required	pam_succeed_if.so user != root quiet_success
@include common-auth
# @include common-yubikey <-- HAD TO COMMENT THIS OUT
auth    optional        pam_gnome_keyring.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close
session required        pam_loginuid.so
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open
session optional        pam_keyinit.so force revoke
session required        pam_limits.so
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-session
session optional        pam_gnome_keyring.so auto_start
@include common-password

/etc/pam.d/sudo:

#%PAM-1.0
session    required   pam_limits.so
session    required   pam_env.so readenv=1 user_readenv=0
session    required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-auth
# @include common-yubikey <-- HAD TO COMMENT THIS OUT
@include common-account
@include common-session-noninteractive

[LDVG]

Hi,

First of all, sincerest apologies for the inconvenience. As part of this update we hardened ownership checks of the authfile to parse the file iff only the owner can write to it. Unfortunately, we appear to have missed that some systems may have a less strict umask configured by default. Is your problem fixed by chmod g-w,o-w /etc/yubico/u2f_keys?

If not, could you please provide debug output?

[mitsukuri]

YES!!! chmod g-w,o-w /etc/yubico/u2f_keys fixes this, thank you so much for such a swift reply!
Have a great day, Ludvig!

[LDVG]

Glad to hear that worked. We'll try to see if we can make this change more obvious for our users.

[mitsukuri]

I was too eager to close, but I guess having it open for a while will make the issue and its resolution more visible to those who'll face it too

[weierophinney]

For those who have your u2f_keys file in $HOME/.config/Yubico/, you need to do the same thing:

chmod g-w,o-w $HOME/.config/Yubico/u2f_keys

[LDVG]

FYI: We have released pam-u2f 1.3.2 to revert this breaking change; pam-u2f will instead log a warning message to syslog, alerting the system administrator about potentially unsafe permissions on the authfile. Again, we apologize for the inconvenience this caused you.

[mitsukuri]

Thank you, guys, and keep up the good work!