Bug 60930 - pam_tally lets you brute force password while account is locked out
pam_tally lets you brute force password while account is locked out
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
7.1
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Aaron Brown
: Security
: 75374 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-09 08:57 EST by Andreas Hansson
Modified: 2007-04-18 12:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-07 10:18:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (12.07 KB, patch)
2004-09-20 10:18 EDT, Tomas Mraz
no flags Details | Diff
Even better patch (13.36 KB, patch)
2004-09-21 08:57 EDT, Tomas Mraz
no flags Details | Diff
Patch applied to upstream (25.40 KB, patch)
2005-01-07 10:18 EST, Tomas Mraz
no flags Details | Diff

  None (edit)
Description Andreas Hansson 2002-03-09 08:57:49 EST
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:
Comment 1 Kjartan Maraas 2003-03-31 15:59:03 EST
Has this changed in later releases?
Comment 2 Doug Sibley 2003-11-19 12:10:37 EST
Should security bugs like this not be hidden?
Comment 3 Tomas Mraz 2004-09-20 10:18:55 EDT
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.
Comment 4 Tomas Mraz 2004-09-21 08:57:53 EDT
Created attachment 104062 [details]
Even better patch

This patch even fixes the fail_locktime problem.
Comment 5 Tomas Mraz 2004-09-21 09:04:35 EDT
*** Bug 75374 has been marked as a duplicate of this bug. ***
Comment 6 Tomas Mraz 2005-01-07 10:18:00 EST
Fixed in upstream CVS
Comment 7 Tomas Mraz 2005-01-07 10:18:58 EST
Created attachment 109471 [details]
Patch applied to upstream

Note You need to log in before you can comment on or make changes to this bug.