Original bug report that led to this one: linux-pam/linux-pam#842 (comment) This "bug" technically has security implications, but I don't believe they're major enough to warrant treating this as a security vulnerability.
PAM has a module, pam_faillock, that allows locking out a user account after a certain number of failed authentication attempts. If the user under attack is not logged into by anyone else, this can work well, however if the account being attacked is logged into and actively being used, it is possible to unlock the account or reset the failed login tally by running a command with sudo that has a NOPASSWD exception present in /etc/sudoers(.d). PAM will see this as a successful authentication, and depending on how PAM is configured it will very likely reset pam_faillock's state directory when this happens, thereby unlocking the account or resetting the tally.
The reason this happens in typical pam_faillock configurations is because sudo usually goes uses the same PAM configuration as most other applications that authenticate users. The configuration will usually integrate pam_faillock directly into the default auth flow, meaning that a failed sudo authentication will count as a failed login, while a successful one will count as a successful login. pam_faillock handles successful logins by resetting the failed login tally that it keeps. This is all well and good, except for the fact that sudo uses the exact same auth flow for basically anything other than sudo -i. Running a command that is given a NOPASSWD exception results in a successful authentication, which PAM then handles as a successful login, which pam_faillock then handles as a "I can reset the failed login tally now" signal.
This is particularly problematic for at least one project (Kicksecure) which uses pam_faillock to prevent a malicious user who gains access to a user account that has sudo privileges from elevating to root by guessing the user password. After enough failed sudo runs, the account is locked and sudo becomes unusable until a legitimate user comes along and unlocks the account. However, due to sudo's interaction with pam_faillock when using NOPASSWD exceptions, a malicious user can trivially bypass this lock by simply running any command that has a NOPASSWD exception every time the account becomes locked.
The current solution I have envisioned for this is that sudo could add another PAM service to
|
if (ISSET(ctx->mode, MODE_ASKPASS) && def_pam_askpass_service != NULL) { |
|
pam_service = def_pam_askpass_service; |
|
} else { |
|
pam_service = ISSET(ctx->mode, MODE_LOGIN_SHELL) ? |
|
def_pam_login_service : def_pam_service; |
|
} |
, which would identify
sudo-nopasswd differently from
sudo. This would allow one to write a PAM configuration that only involved
pam_faillock with typical sudo runs, and kept it out of the auth flow for NOPASSWD commands. That way NOPASSWD commands would still succeed, but they would not unlock the account.
Original bug report that led to this one: linux-pam/linux-pam#842 (comment) This "bug" technically has security implications, but I don't believe they're major enough to warrant treating this as a security vulnerability.
PAM has a module,
pam_faillock, that allows locking out a user account after a certain number of failed authentication attempts. If the user under attack is not logged into by anyone else, this can work well, however if the account being attacked is logged into and actively being used, it is possible to unlock the account or reset the failed login tally by running a command with sudo that has a NOPASSWD exception present in/etc/sudoers(.d). PAM will see this as a successful authentication, and depending on how PAM is configured it will very likely resetpam_faillock's state directory when this happens, thereby unlocking the account or resetting the tally.The reason this happens in typical
pam_faillockconfigurations is becausesudousually goes uses the same PAM configuration as most other applications that authenticate users. The configuration will usually integratepam_faillockdirectly into the default auth flow, meaning that a failedsudoauthentication will count as a failed login, while a successful one will count as a successful login.pam_faillockhandles successful logins by resetting the failed login tally that it keeps. This is all well and good, except for the fact thatsudouses the exact same auth flow for basically anything other thansudo -i. Running a command that is given a NOPASSWD exception results in a successful authentication, which PAM then handles as a successful login, whichpam_faillockthen handles as a "I can reset the failed login tally now" signal.This is particularly problematic for at least one project (Kicksecure) which uses
pam_faillockto prevent a malicious user who gains access to a user account that has sudo privileges from elevating to root by guessing the user password. After enough failedsudoruns, the account is locked andsudobecomes unusable until a legitimate user comes along and unlocks the account. However, due tosudo's interaction withpam_faillockwhen using NOPASSWD exceptions, a malicious user can trivially bypass this lock by simply running any command that has a NOPASSWD exception every time the account becomes locked.The current solution I have envisioned for this is that
sudocould add another PAM service tosudo/plugins/sudoers/auth/pam.c
Lines 220 to 225 in 17aa768
sudo-nopasswddifferently fromsudo. This would allow one to write a PAM configuration that only involvedpam_faillockwith typical sudo runs, and kept it out of the auth flow for NOPASSWD commands. That way NOPASSWD commands would still succeed, but they would not unlock the account.