Bug 60213 - Authentication failure for long DES passwords (fix included)
Authentication failure for long DES passwords (fix included)
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Aaron Brown
http://sourceforge.net/tracker/?func=...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-21 22:16 EST by Need Real Name
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-22 13:58:53 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)
Here is a patch against the latest version of support.c and unix_chkpwd.c in pam_unix (647 bytes, patch)
2002-02-22 13:56 EST, Need Real Name
no flags Details | Diff

  None (edit)
Description Need Real Name 2002-02-21 22:16:26 EST
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 13:56:03 EST
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 13:58:49 EST
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-07 19:15:45 EST
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.

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