Bug 136855 - Unexpected behavior with PAM, openssh and blank passwords
Unexpected behavior with PAM, openssh and blank passwords
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pam (Show other bugs)
3.0
All Linux
medium Severity low
: ---
: ---
Assigned To: Tomas Mraz
Jay Turner
impact=low,public=20041022
: Security
: 148766 (view as bug list)
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-10-22 14:44 EDT by Elliot Kendall
Modified: 2015-01-07 19:08 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-28 11:39:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Elliot Kendall 2004-10-22 14:44:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041007 Galeon/1.3.17 (Debian package 1.3.17-2)

Description of problem:
When a user has a blank system password and the PermitEmptyPasswords
option is set to "no" in /etc/ssh/sshd_config, the user can log in
with any password. This is due to a known issue with SSH and PAM
interaction (http://www.openssh.com/faq.html#3.2).

SSH can't tell whether a user's system password is empty, and so can
only reject attempts to log in using a blank password when
PermitEmptyPasswords is set to "no". Everything else gets passed along
to PAM, which as long as "nullok" is set in the appropriate auth line,
will approve any input password when the user's system password is blank.

I suggest making ssh not use the system-auth auth stack by default,
but instead use its own config with does not include "nullok".

Version-Release number of selected component (if applicable):
pam-0.75-58

How reproducible:
Always

Steps to Reproduce:
1. Set a null password on some account
2. Be sure PermitEmptyPasswords is set to "no" in /etc/ssh/sshd_config
3. Log into the account via SSH, entering any password when prompted
    

Actual Results:  The user with a blank password is able to log in

Expected Results:  The user with a blank password should be unable to
log in

Additional info:
Comment 1 Tomas Mraz 2004-10-25 04:15:25 EDT
Don't you think it would be better to fix pam to not accept nonempty
password when the user's password is empty?
Comment 2 Lee Whatley 2004-10-25 09:48:17 EDT
I'd like to suggest that the "nullok" option be taken out of all of
the default PAM configuration files in future releases.  It would make
for a more secure default installation, don't you think?   
Comment 3 Elliot Kendall 2004-10-25 10:30:04 EDT
I figured that accepting any input password for an account with a
blank system password is the "correct" behavior for PAM, since the
OpenSSH people know of the problem and have evidently been unable to
convince the PAM people to change anything. I can't find any RFC or
mailing list discussion to back that up, though.

This bug is almost a duplicate of bug 8083, though, and that seems to
have been fixed with a patch to the PAM code. I can't figure out
exactly what the change was, though, since the RedHat 6.1 update SRPM
I'm looking at doesn't use seperate patch files.
Comment 4 Tomas Mraz 2004-10-25 10:44:44 EDT
Note that current Fedora doesn't have this bug.
And nullok option doesn't enable to set the empty password by user,
the sysadmin has to explicitely edit the /etc/passwd to empty the
password for given user.
Comment 6 Tomas Mraz 2005-02-15 09:40:56 EST
*** Bug 148766 has been marked as a duplicate of this bug. ***
Comment 7 John Flanagan 2005-04-28 11:39:37 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-064.html
Comment 8 Tim Powers 2005-05-18 10:49:13 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-062.html

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