OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/7384
Full headers

From: ghola@rebelbase.com
Subject: Assert Crash in ppolicy_ctrls_cleanup
Compose comment
Download message
State:
0 replies:
3 followups: 1 2 3

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 11 Sep 2012 18:00:46 +0000
From: ghola@rebelbase.com
To: openldap-its@OpenLDAP.org
Subject: Assert Crash in ppolicy_ctrls_cleanup
Full_Name: Duncan Idaho
Version: 2.4.32
OS: Centos 5.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (216.148.0.72)


We are seeing this a few times a week in our environment.

#0  0x0000003874c30265 in raise () from /lib64/libc.so.6
#1  0x0000003874c31d10 in abort () from /lib64/libc.so.6
#2  0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6
#3  0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10,
oldctrls=0x11251620) at ppolicy.c:870
#4  0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10)
at ppolicy.c:895
#5  0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at
result.c:541
#6  0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at
result.c:733
#7  0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10)
at result.c:860
#8  0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158
#9  0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10,
which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671
#10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10,
which=op_bind) at backover.c:723
#11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at
backover.c:738
#12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0)
at op.c:210
#13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at
op.c:243
#14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10,
which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671
#15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10,
which=op_bind) at backover.c:723
#16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at
backover.c:738
#17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at
bind.c:383
#18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205
#19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60,
arg_v=0x11144d40) at connection.c:1150
#20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at
connection.c:1286
#21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at
tpool.c:688
#22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0
#23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6
#24 0x0000000000000000 in ?? ()

Followup 1

Download message
Date: Thu, 27 Sep 2012 08:15:39 -0700
From: Howard Chu <hyc@symas.com>
To: ghola@rebelbase.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
ghola@rebelbase.com wrote:
> Full_Name: Duncan Idaho
> Version: 2.4.32
> OS: Centos 5.5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (216.148.0.72)
>
>
> We are seeing this a few times a week in our environment.

Can you provide a sample config to reproduce the issue? What is the exact 
error message on stderr that accompanies this assert?

> #0  0x0000003874c30265 in raise () from /lib64/libc.so.6
> #1  0x0000003874c31d10 in abort () from /lib64/libc.so.6
> #2  0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6
> #3  0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10,
> oldctrls=0x11251620) at ppolicy.c:870
> #4  0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40,
rs=0x42e3cc10)
> at ppolicy.c:895
> #5  0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10)
at
> result.c:541
> #6  0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10)
at
> result.c:733
> #7  0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40,
rs=0x42e3cc10)
> at result.c:860
> #8  0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at
bind.c:158
> #9  0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10,
> which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671
> #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10,
> which=op_bind) at backover.c:723
> #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at
> backover.c:738
> #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10,
which=0)
> at op.c:210
> #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10)
at
> op.c:243
> #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10,
> which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671
> #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10,
> which=op_bind) at backover.c:723
> #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at
> backover.c:738
> #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at
> bind.c:383
> #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at
bind.c:205
> #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60,
> arg_v=0x11144d40) at connection.c:1150
> #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60,
argv=0xc7) at
> connection.c:1286
> #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80)
at
> tpool.c:688
> #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0
> #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6
> #24 0x0000000000000000 in ?? ()
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
Date: Thu, 27 Sep 2012 11:02:45 -0700
Subject: Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
From: Duncan Idaho <ghola@rebelbase.com>
To: Howard Chu <hyc@symas.com>
Cc: openldap-its@openldap.org
I'll have to see if I can track down stderr when this happens.  Here
is the configuration on that host:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/custom.schema
include /etc/openldap/schema/ldapux.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/puppet.schema

TLSVerifyClient never
TLSCertificateFile /etc/openldap/slapd.pem
TLSCertificateKeyFile /etc/openldap/slapd.pem
TLSCACertificateFile /etc/openldap/ca.pem

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
loglevel sync

reverse-lookup on

# old ACLs
include /etc/openldap/legacy.acl

# new ACLs
include /etc/openldap/new.acl

# Allow anonymous access to userPassword for directory binds
access to dn.onelevel="ou=users,dc=example2,dc=net" attrs="userPassword"
  by anonymous auth
  by self read
  by * none

# Secure unix passwords
access to dn.onelevel="ou=users,ou=posix,dc=example2,dc=net"
attrs="userPassword"
  by self read
  by * none

# Secure unix passwords
# legacy
access to dn.onelevel="ou=people,dc=example,dc=com" attrs="userPassword"
  by self read
  by * none

access to dn.onelevel="ou=people,dc=example2,dc=net" attrs="userPassword"
  by self read
  by * none

# posix info is public
access to dn.subtree="ou=posix,dc=example2,dc=net"
  by * read

# posix info is public
# legacy
access to dn.subtree="ou=people,dc=example,dc=com"
  by * read

access to dn.subtree="ou=people,dc=example2,dc=net"
  by * read

access to dn.subtree="ou=group,dc=example2,dc=net"
  by * read

# access to the base dn
access to dn.base="dc=example2,dc=net"
  by * read

# access to the base dn
# legacy
access to dn.base="dc=example,dc=com"
  by * none

# basic access
# legacy
access to dn.subtree="dc=example,dc=com"
  by * none

# basic access
access to *
  by users read
  by * none

database hdb
suffix "dc=example2,dc=net"
rootdn "cn=manager,dc=example2,dc=net"
rootpw password
index objectClass,uidNumber,gidNumber eq
index cn,sn,uid,displayName           pres,sub,eq
index memberUid,mail,givenname                eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName   eq
index entryUUID,modifyTimestamp eq
index location eq
index service subinitial
index uniqueMember eq
directory /var/lib/ldap
sizelimit unlimited
cachesize 1000000
idlcachesize 3000000

overlay ppolicy
ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net

syncrepl rid=1
    provider=ldap://syncrepl.example2.net:389
    type=refreshAndPersist
    searchbase="dc=example2,dc=net"
    bindmethod=simple
    binddn=user=sync-user,ou=users,dc=example2,dc=net
    starttls=critical
    credentials=password
    retry="10 100 300 +"

database relay
suffix "dc=example,dc=com"
overlay rwm
rwm-suffixmassage "dc=example,dc=com" "dc=example2,dc=net"
overlay ppolicy
ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net



Followup 3

Download message
Date: Tue, 11 Oct 2016 19:52:08 -0700
From: Ryan Tandy <ryan@nardis.ca>
To: openldap-its@openldap.org
Subject: Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
Just noting that one way to reproduce this assert reliably is to bind to 
an existing entry, through the relay, with an incorrect password.

The important part of the config is:

database mdb
suffix dc=example,dc=com
[...]

overlay ppolicy

database relay
suffix o=example

overlay rwm
rwm-suffixmassage o=example dc=example,dc=com

overlay ppolicy

Then, binding through the relay:

$ ldapwhoami -x -D uid=test,o=example -w zzz -e ppolicy

slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)'
failed.

Same as when someone accidentally attaches two ppolicy instances to a 
single database. Not totally sure, but I suspect it's wrong here too: I 
don't see what the ppolicy attached to the relay is supposed to add in 
this case. I guess in theory they could have different configuration?  
wrt. e.g. ppolicy_use_lockout, or even pwdLockout/pwdMustChange via a 
different ppolicy_default...

Wondering if it would make sense for add_passcontrol to look for a 
ppolicy control already existing on the op, and try to fail gracefully 
if so, instead of hitting this on the way out.

Binding to the same entry with the correct password...

$ ldapwhoami -x -D uid=test,o=example -w test -e ppolicy

currently hits the same segfault reported in ITS#7966.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org