From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Description of problem: When an account is locked out by pam_tally, it is still possible to brute force its password because the response returned for the right password is different from the one returned for the wrong password. Version-Release number of selected component (if applicable): pam-0.75-18.7 How reproducible: Always Steps to Reproduce: 1. Add pam_tally to your pam config, something like this: auth required /lib/security/pam_tally.so no_magic_root account required /lib/security/pam_tally.so deny=5 no_magic_root 2. Try to login 5 times with an invalid password. 3. Now alternate between the correct and invalid password and observe the responses. Actual Results: When telnetting to the machine to login, with the right password I get: Red Hat Linux release 7.1 (Seawolf) Kernel 2.4.9-21 on an i586 login: andreas Password: Authentication failure And with the wrong password I get: Red Hat Linux release 7.1 (Seawolf) Kernel 2.4.9-21 on an i586 login: andreas Password: Login incorrect login: When using ssh, for the wrong password I get a 3 second delay before it reports an error while for the right password the error is immediate. Expected Results: There should be no noticable difference in response for the right password and the wrong password while the account is locked. Additional info:
Has this changed in later releases?
Should security bugs like this not be hidden?
Created attachment 104015 [details] Proposed patch This patch solves the issue by moving the tally checking functionality to the auth group. However it's necessary to update the pam configuration by moving the required options (as deny=N) to the auth group. Also note that when it seems that it doesn't work as expected check if the pam_tally module is called/not called on both auth and account groups. For example su on Fedora Core effectively skips the pam_tally for root because pam_rootok is first module called in auth group and has sufficient as control value. This will imbalance the calls to the pam_tally module. To rebalance it you need to put an 'pam_succeed_if.so uid eq 0 use_uid quiet' as the first module for su in account group.
Created attachment 104062 [details] Even better patch This patch even fixes the fail_locktime problem.
*** Bug 75374 has been marked as a duplicate of this bug. ***
Fixed in upstream CVS
Created attachment 109471 [details] Patch applied to upstream