Bug 179723 - (ldappasswd_crash) crash after succesful pwdchange via ldappasswd
crash after succesful pwdchange via ldappasswd
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - Password Policy (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Viktor Ashirov
:
Depends On:
Blocks: 152373 183369 240316 FDS1.1.0
  Show dependency treegraph
 
Reported: 2006-02-02 09:44 EST by Rich Megginson
Modified: 2015-12-07 11:43 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:43:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
nss_ldap config file at use when I experienced the bug (233 bytes, text/plain)
2006-02-02 11:23 EST, Jo De Troy
no flags Details
openldap-clients config file (130 bytes, text/plain)
2006-02-02 11:24 EST, Jo De Troy
no flags Details
slapd-access log (375.92 KB, text/plain)
2006-02-02 11:25 EST, Jo De Troy
no flags Details
errors log (3.19 KB, text/plain)
2006-02-02 11:27 EST, Jo De Troy
no flags Details

  None (edit)
Description Rich Megginson 2006-02-02 09:44:24 EST
Fedora DS 1.0.1 on RHEL4
Using the ldappasswd command to change a user's password crashes the server.  I
tried to reproduce on Fedora Core 4, but I could not reproduce the crash.
You have to first enable SSL on the server (see the Howto:SSL on the wiki)
because you cannot use ldappasswd without SSL.  Then, as a user (I used a user
from the Example.ldif), attempt to change your own password.
Comment 1 Rich Megginson 2006-02-02 10:04:57 EST
Need to reproduce on RHEL4 and the original reporter is going to attach some
config files and logs to this bug.
Comment 2 Jo De Troy 2006-02-02 11:23:09 EST
Created attachment 124052 [details]
nss_ldap config file at use when I experienced the bug

/etc/ldap.conf
Comment 3 Jo De Troy 2006-02-02 11:24:24 EST
Created attachment 124053 [details]
openldap-clients config file

/etc/openldap/ldap.conf file being used
Comment 4 Jo De Troy 2006-02-02 11:25:57 EST
Created attachment 124054 [details]
slapd-access log 

/opt/fedora-ds/slapd-ldapserver/slapd-access file
Comment 5 Jo De Troy 2006-02-02 11:27:00 EST
Created attachment 124055 [details]
errors log

/opt/fedora-ds/slapd-ldapserver/slapd-errors
Comment 6 Jo De Troy 2006-02-02 11:28:50 EST
I have FDS 1.0.1 running on CentOs 4.2
Comment 7 Rich Megginson 2006-02-14 11:53:08 EST
It looks as though none of the attempts to change the password were successful,
despite what ldappasswd may have said.  If you look at the attached access log,
and search for passwd_modify_extop, you will see that all of the attempts failed
with one of the following result codes:

err=13 - CONFIDENTIALITY_REQUIRED - an attempt to use the password_modify_extop
was made on an insecure connection
err=89 - INVALID_PARAM - either the old or the new password was not given
err=19 - CONSTRAINT_VIOLATION - the new password did not conform to the syntax
(i.e. not long enough), or was already in the password history, or the user is
not allowed to change it yet, or the user exceeded the password retry limit.

I'm trying to see if any of the error conditions cause a failure.  So far,
neither err=13 nor err=89 seems to cause any problems.  I'm going to turn on
password syntax checking to see if that breaks anything.

Comment 8 Rich Megginson 2006-02-14 16:33:26 EST
I've tried and tried repeatedly to get this to fail, but so far, no crash.  I'm
using Fedora Core 4.  I even ran the code under valgrind 2.4 - I found some
memory leaks in the password extop code, but no other problems that would cause
a crash.

What is your exact ldappasswd command? I'm using something like:
ldappasswd -ZZ -x -h localhost -p 10000 -a "98765432109876543210" -s
"01234567890123456789" -D "uid=scarter,ou=people,dc=example,dc=com" -w
98765432109876543210 "uid=scarter,ou=people,dc=example,dc=com"

I've tried it without the DN on the end (defaults to the BIND DN), with and
without the -ZZ, -s, and -a, and various combinations.
Comment 9 Jo De Troy 2006-02-28 16:21:49 EST
The command I used to execute, which now I see has an extra -ZZ in there
#ldappasswd -ZZ -x -d 3 -h ldapserver.fqdn -D
'uid=jdtroy,ou=People,dc=example,dc=com' -w oldpwd -S -a oldpwd  -ZZ
'uid=jdtroy,ou=People,dc=example,dc=com'
 
I retried with the command you wrote down above, and I still have the same
problem. I am using policies [password history (remember:5) - password
expiration: max 90 days - warn: 14 days - lockout after 3 failures - check
password syntax (min 6 characters + use MD5 hash algorithm)] Below the command I
used now:
# ldappasswd -ZZ -x  -h ldapserver.fqdn -a odlpwd -s newpwd -D
'uid=jdtroy,ou=People,dc=example,dc=com' -w oldpwd 
'uid=jdtroy,ou=People,dc=example,dc=com'
Comment 10 Rich Megginson 2006-02-28 17:53:48 EST
Using the latest code (CVS head - proposed FDS 1.0.2 candidate) I cannot
reproduce.  I tried both of the forms above.  We have fixed some bugs in this
area of the code, so perhaps those fixes solved this problem as well.
Comment 11 Mike Jackson 2006-03-04 15:36:38 EST
I am currently able to crash the server every time after a successful password
modify extended operation, with 1.0.2 release.

It didn't crash before I had enabled password expiration. After I disabled
password expiration and tested again, it continues to crash.
Comment 12 Rich Megginson 2006-03-06 13:17:49 EST
*** passwd_extop.c.~1.7.~	2006-02-15 14:16:53.000000000 -0700
--- passwd_extop.c	2006-03-06 10:47:51.000000000 -0700
***************
*** 135,141 ****
  static int passwd_apply_mods(const char *dn, Slapi_Mods *mods) 
  {
  	Slapi_PBlock pb;
- 	Slapi_Operation *operation= NULL;
  	int ret=0;
  
  	LDAPDebug( LDAP_DEBUG_TRACE, "=> passwd_apply_mods\n", 0, 0, 0 );
--- 135,140 ----
***************
*** 150,158 ****
  		  pw_get_componentID(), /* PluginID */
  		  0); /* Flags */ 
  
- 	 /* Plugin operations are INTERNAL by default, bypass it to enforce ACL checks */
- 	 slapi_pblock_get (&pb, SLAPI_OPERATION, &operation);
- 
  	 ret =slapi_modify_internal_pb (&pb);
    
  	 slapi_pblock_get(&pb, SLAPI_PLUGIN_INTOP_RESULT, &ret);
--- 149,154 ----

*** pw.c.~1.9.~	2006-02-15 14:32:11.000000000 -0700
--- pw.c	2006-03-06 10:58:16.000000000 -0700
***************
*** 647,654 ****
  
  	pw_apply_mods(dn, &smods);
  	slapi_mods_done(&smods);
! 	/* reset c_needpw to 0 */
! 	pb->pb_conn->c_needpw = 0;
      return 0;
  }
  
--- 647,656 ----
  
  	pw_apply_mods(dn, &smods);
  	slapi_mods_done(&smods);
!     if (pb->pb_conn) { /* no conn for internal op */
!         /* reset c_needpw to 0 */
!         pb->pb_conn->c_needpw = 0;
!     }
      return 0;
  }
  
Comment 13 Rich Megginson 2006-03-06 14:57:20 EST
Reviewed by: Pete, Nathan (Thanks!)
Files: passwd_extop.c pw.c
Branch: HEAD
Fix Description: The passwd_extop code does an internal operation to 
change the password.  Some of this code is only intended to be called 
for external operations where you have a conn structure.  The one place 
in particular which caused this bug is in update_pw_info, where it is 
only triggered if you must change the password or password expiration is 
in effect.  The fix is to just check to see if the pb_conn is not null.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no

/cvs/dirsec/ldapserver/ldap/servers/slapd/pw.c,v  <--  pw.c
new revision: 1.10; previous revision: 1.9
done

Checking in passwd_extop.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/passwd_extop.c,v  <--  passwd_extop.c
new revision: 1.8; previous revision: 1.7
done
Comment 14 Anh Nguyen 2007-12-07 11:15:19 EST
Verified. See attached.
Comment 15 Anh Nguyen 2007-12-07 11:17:26 EST
Oops. I am addressing the wrong bug #. Changed status back to MODIFIED
Comment 17 Chandrasekar Kannan 2007-12-26 19:32:54 EST
ignore comment #16 above.

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