Bug 60213

Summary: Authentication failure for long DES passwords (fix included)
Product: [Retired] Red Hat Linux Reporter: Need Real Name <sstrollo>
Component: pamAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
URL: http://sourceforge.net/tracker/?func=detail&atid=306663&aid=521318&group_id=6663
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-22 18:58:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Here is a patch against the latest version of support.c and unix_chkpwd.c in pam_unix none

Description Need Real Name 2002-02-22 03:16:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22smp i686; Nav)

Description of problem:
I discovered this when using NIS to a Solaris machine, but it is
equally broken for local DES passwords. If your password is longer than 8
characters you can not log in if you are using DES passwords.

The problem is that longer passwords makes bigcrypt() produce
longer crypt strings - but if you are still using 13 character
crypted passwords the strings won't match. To support both longer
and shorter crypt strings the strcmp() in support.c should be replaced with a
strncmp() see patch below.


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


How reproducible:
Always

Steps to Reproduce:
1. Install RedHat 7.2, choose not to use MD5 passwords or shadow passwords
2. Give any user a password longer than 8 character
3. Try to log in
	

Actual Results:  Authentication failure - i.e. you can't log in

Expected Results:  I should have been allowed in :-)

Additional info:

Here is a patch against pam-0.75 (sorry but I guess this web form will break the
formatting but it is not that hard to figure it out:-)

*** modules/pam_unix/support.c.ORIG     Mon Sep 24 07:50:44 2001
--- modules/pam_unix/support.c  Fri Feb 22 02:55:41 2002
***************
*** 712,718 ****
                        /* the moment of truth -- do we agree with the password?
*/
                        D(("comparing state of pp[%s] and salt[%s]", pp, salt));
  
!                       if (strcmp(pp, salt) == 0) {
                                retval = PAM_SUCCESS;
                        } else {
                                retval = PAM_AUTH_ERR;
--- 712,718 ----
                        /* the moment of truth -- do we agree with the password?
*/
                        D(("comparing state of pp[%s] and salt[%s]", pp, salt));
  
!                       if (strncmp(pp, salt, strlen(salt)) == 0) {
                                retval = PAM_SUCCESS;
                        } else {
                                retval = PAM_AUTH_ERR;

Comment 1 Need Real Name 2002-02-22 18:56:03 UTC
Created attachment 46420 [details]
Here is a patch against the latest version of support.c and unix_chkpwd.c in pam_unix

Comment 2 Need Real Name 2002-02-22 18:58:49 UTC
The patch uploaded is the same as I posted on sourceforge (but I couldn't upload
it there...) See

http://sourceforge.net/tracker/?func=detail&atid=306663&aid=521318&group_id=6663

and 

http://sourceforge.net/tracker/?func=detail&atid=106663&aid=521314&group_id=6663


Comment 3 Nalin Dahyabhai 2002-03-08 00:15:45 UTC
Sorry, that won't work right.  If the current password is "*", crypt() will
actually return "*", even though it's an invalid salt, and strncmp() will return
a successful code.  The current errata for RHL 7.2 (0.75-19) should fix this
correctly.  Please reopen this bug ID if that is not the case.