Bug 136855 - Unexpected behavior with PAM, openssh and blank passwords
Summary: Unexpected behavior with PAM, openssh and blank passwords
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pam   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Jay Turner
URL:
Whiteboard: impact=low,public=20041022
Keywords: Security
: 148766 (view as bug list)
Depends On:
Blocks: 132991
TreeView+ depends on / blocked
 
Reported: 2004-10-22 18:44 UTC by Elliot Kendall
Modified: 2015-01-08 00:08 UTC (History)
4 users (show)

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


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:062 normal SHIPPED_LIVE pam bug fix update 2005-05-18 04:00:00 UTC
Red Hat Product Errata RHBA-2005:064 low SHIPPED_LIVE pam bug fix update 2005-04-28 04:00:00 UTC

Description Elliot Kendall 2004-10-22 18:44:29 UTC
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 08:15:25 UTC
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 13:48:17 UTC
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 14:30:04 UTC
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 14:44:44 UTC
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 14:40:56 UTC
*** Bug 148766 has been marked as a duplicate of this bug. ***

Comment 7 John Flanagan 2005-04-28 15:39:37 UTC
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 14:49:13 UTC
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.