OpenLDAP 2.4.45 possible denial of service vulnerability?
by Juergen.Sprenger＠swisscom.com
Hi,
After upgrading to the latest Release (Solaris 11.3 SRU35, OpenLDAP 2.4.45) we are experiencing massive workloads caused by single clients consuming all available threads and CPU-resources. Service does not longer respond to requests, even cn=monitor on loopback interface stops to respond properly.
OS:
# pkg info entire
Name: entire
Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0).
Description: This package constrains system package versions to the same
build. WARNING: Proper system update and correct package
selection depend on the presence of this incorporation.
Removing this package will result in an unsupported system.
For more information see:
https://support.oracle.com/rs?type=doc&id=2045311.1
Category: Meta Packages/Incorporations
State: Installed
Publisher: solaris
Version: 0.5.11 (Oracle Solaris 11.3.35.6.0)
Build Release: 5.11
Branch: 0.175.3.35.0.6.0
Packaging Date: August 10, 2018 03:22:59 PM
Size: 5.46 kB
FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z
OpenSSL:
# pkg info entire
Name: entire
Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0).
Description: This package constrains system package versions to the same
build. WARNING: Proper system update and correct package
selection depend on the presence of this incorporation.
Removing this package will result in an unsupported system.
For more information see:
https://support.oracle.com/rs?type=doc&id=2045311.1
Category: Meta Packages/Incorporations
State: Installed
Publisher: solaris
Version: 0.5.11 (Oracle Solaris 11.3.35.6.0)
Build Release: 5.11
Branch: 0.175.3.35.0.6.0
Packaging Date: August 10, 2018 03:22:59 PM
Size: 5.46 kB
FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z
OpenLDAP:
# pkg info entire
Name: entire
Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0).
Description: This package constrains system package versions to the same
build. WARNING: Proper system update and correct package
selection depend on the presence of this incorporation.
Removing this package will result in an unsupported system.
For more information see:
https://support.oracle.com/rs?type=doc&id=2045311.1
Category: Meta Packages/Incorporations
State: Installed
Publisher: solaris
Version: 0.5.11 (Oracle Solaris 11.3.35.6.0)
Build Release: 5.11
Branch: 0.175.3.35.0.6.0
Packaging Date: August 10, 2018 03:22:59 PM
Size: 5.46 kB
FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z
Part of slapd.conf:
loglevel none stats sync
sizelimit 15000
timelimit 30
threads 64
tool-threads 8
idletimeout 0
writetimeout 0
security tls=0
conn_max_pending 100
conn_max_pending_auth 1000
database mdb
suffix "dc=scom"
rootdn "cn=*****"
rootpw {SSHA}*****
maxsize 17179869184
maxreaders 4096
searchstack 64
checkpoint 0 1
dbnosync
Machine is a X6-2, 44 cores, 88 threads, 256GB RAM:
# prtdiag
System Configuration: Oracle Corporation ORACLE SERVER X6-2
BIOS Configuration: American Megatrends Inc. 38070000 12/16/2016
BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)
==== Processor Sockets ====================================
Version Location Tag
-------------------------------- --------------------------
Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz P0
Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz P1
Even monitoring (cn=monitor) is no longer accessible when this occurs.
So far we experienced this behavior with clients of Oracle Enterprise Linux 6.x, Redhat Enterprise Linux 6.x and AIX. Service requests are opened at vendors support, but I'd prefer to have an installation which is less vulnerable and more resilient to issues of this kind.
No problems or issues with Solaris and HPUX clients.
Has anyone experienced similar problems or suggestions for configuration?
To avoid performance issues loglevel is now "none stats sync" but can be changed for some time to track down the cause.
Best regards
Jürgen Sprenger
4 years, 7 months
ldap client failing
by sami's strat
I'm installing ldap client on CentOS 7 hosts. Some work, some do not. For
those that don't work, I don't know why. The install / setup process I
used was the same on all hosts.
yum install nss-pam-ldapd openldap-clients -y
authconfig --enableldap --enableldapauth --ldapserver=172.19.33.1
--ldapbasedn="dc=users,dc=domain,dc=com" --enablemkhomedir --update
systemctl start nslcd
getent passwd useraccount
The last command fails. Vital signs on all hosts are fine, network,
connectivity, ports, ntp, etc..
Where do I even begin troubleshooting the failure?
Thanks in advance.
4 years, 7 months
RE: OpenLDAP 2.4.45 possible denial of service vulnerability?
by Juergen.Sprenger＠swisscom.com
Hi Henrik,
Many thanks for Your advice,
- Yes, we started using mdb-backend and did not use it before.
- LDAP tree is not very large, a slapcat dump has about 1.050 Million lines and less than 50'000 dn entries.
- LDAP tree contains attributes 21661 of type aliasedObjectName
- Yes, alias-dereferencing is used and set to always. Clients should not, but may do searches using "sub" instead of "one" .
I will check whether using hdb will mitigate the problem.
Jürgen
-----Original Message-----
From: Henrik Bohnenkamp [mailto:hbohnenkamp@united-internet.de]
Sent: Mittwoch, 30. Januar 2019 12:23
To: Sprenger Jürgen, INI-ONE-CIS-SDI-HES <Juergen.Sprenger(a)swisscom.com>
Subject: Re: OpenLDAP 2.4.45 possible denial of service vulnerability?
On Wed, Jan 30, 2019 at 10:17:47AM +0000, Juergen.Sprenger(a)swisscom.com wrote:
Hi Jürgen,
if you can answer all of the following questions with "yes", you might have the problem described in ITS#8875/ITS#7657
(http://www.openldap.org/its/index.cgi/Incoming?id=8875;selectid=8875):
- with the upgrade to 2.4.45, you started to use the mdb-backend, and
did not use it before
- your LDAP tree is large (> 1 Million entries)
- the LDAP tree contains many alias objects (> 64k )
- the clients causing the trouble make searches with scope "sub", and alias-dereferencing
set to "always"
That's essential the 4 conditions that lead to a problem at my organisation similar to the one you described. Workaround was to go back to the hdb backend.
Henrik
--
Henrik Bohnenkamp
4 years, 7 months
authz-regexp failures
by Dieter Klünter
Hi,
I am facing some problems with authz-regexp configurations. These
configurations run for ages on several systems. I only discovered
recently, that some errors occured:
# ldapwhoami -Y EXTERNAL -H ldapi:///
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
The appropriate lines in slapd.conf:
authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth"
"cn=config"
There are still a few more authz-regexp rules that don't work anymore.
Any ideas?
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
4 years, 7 months
Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40
by Janne Peltonen
Hi!
We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer
"meta" backend had some issues, so I couldn't use that one). Most of the time,
the proxy bind goes OK, but sometimes, the connection goes like this (proxy
log, using ldaps):
--clip--
Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636)
Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256
Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 BIND dn="<removed>" method=128
Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed
Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost)
--clip--
On the backend, this appears to be the case that a new connection kind of
overruns the old one; see what happens with connection 6983:
--clip--
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389)
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389)
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text=
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text=
[SRCH and result lines]
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND
Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed
--clip--
This doesn't seem to have any correlation to the amount of binds of server
load, at least that I'm aware - and anyway, the servers are nowhere near at
capacity - we only get ~2 binds per second.
Normal connection would look like this:
--clip--
Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636)
Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256
Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128
Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0
Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text=
[SRCH and SEARCH RESULT lines]
Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND
Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed
--clip--
So this far, it looks as if the problem was that if we accept a second
connection for the same client before the proxy has had time to do a bind (or
indeed, a STARTTLS for the bind) on the backend for the second connection.
But we seem to be getting spurious Start TLS failed messages also without any
competing connections. Here's one using ldap+STARTTLS but no other ACCEPTs
anywhere near:
--clip--
Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389)
Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS
Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text=
Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256
Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128
Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed
Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost)
--clip--
on the proxy, and backend:
--clip--
Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389)
Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS
Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text=
Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure)
--clip--
Succesful ldap+starttls connection on proxy:
--clip--
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 ACCEPT from IP=128.214.173.137:48700 (IP=0.0.0.0:389)
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 STARTTLS
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 RESULT oid= err=0 text=
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 TLS established tls_ssf=256 ssf=256
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" method=128
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 RESULT tag=97 err=0 text=
[SRCH and SEARCH RESULT lines]
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=3 UNBIND
Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 closed
--clip--
Any ideas what could be causing these? It's a bit hard to pinpoint the problem,
since it happens so rarely - we seem to get a couple dozen of these every hour
to around 16 000 succesful binds, not really depending on system load. This is
RHEL 7 and OpenLDAP 2.4.40.
It may be the case that the same DN binding very often increases the
probability of a Start TLS failed error, which I guess would be the first case
(a new ACCEPT + BIND for a DN too soon after the previous one). But as I said,
these seem to also sometimes appear even without any other connections being
opened at the same time. (Although there might be some old connections open for
the same DN.)
--Janne Peltonen
University of Helsinki
4 years, 7 months
openldap proxy with uid/gid lookup cache
by vadud3＠gmail.com
How do I include uid/gid lookup caching to my openldap proxy server?
$ cat slapd.conf
### Schema includes ###########################################################
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
## Module paths ##############################################################
modulepath /usr/lib64/openldap/
moduleload back_ldap
# Main settings ###############################################################
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
sizelimit unlimited
TLSCertificateFile /root/data/certs/ldap.crt
TLSCertificateKeyFile /root/data/certs/ldap.key
### Database definition (Proxy to AD) #########################################
database ldap
readonly yes
protocol-version 3
rebind-as-user yes
uri "ldaps://ldap.example.com:1636"
suffix "ou=People,dc=example,dc=net"
### Logging ###################################################################
loglevel 0
(ignore the other similar email with no subjects.. apologize)
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
4 years, 8 months
Copying SSHA userPassword from Oracle to OpenLDAP
by Nicholas Carl
Currently doing a targeted sync of userPassword field from one LDAP to
another following this process.
1) Query using ldapsearch and grab userPassword field.
2) Deode string using base64 –d
3) Import resultant encrypted password into other ldap using
ldapmodify.
This process worked when the password decoded into {crypt} format, but
after they upgraded and changed to {SSHA} format passwords, it no longer
works. Also confirmed with Oracle LDAP admins that the decode matches our
{SSHA} string.
*Is there some additional configuration information I need to request from
the oracle LDAP server administrators for server or client config in
openldap?*
# Querying other LDAP server
$ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword
userPassword::
e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ=
$ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword |
base64 -d
{SSHA}KxMAUhDf4cFLUwUDFPoUC0SoDWQoG6NsKE5YQg==base64: invalid input
## After importing decrypted into new server, the encrypted string matches.
$ ldapsearch -h openLDAPServer -D - -w - "uid=-" | grep ^userPassword
userPassword::
e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ=
4 years, 8 months
uniqueness on multiple attributes
by A. Schulze
Hello,
my goal it to extend a uniqueness configuration. I do already enforce uniqueness of mail addresses:
slapd.conf:
moduleload unique.la
overlay unique
unique_uri ldap:///dc=basedn?mail?sub?
that works.
Now also address rewriting data should be migrated LDAP. Rewriting addresses are stored in the attribute "mailalternateaddress"
Requirement: no address may occur twice no matter if stored as "mail" or "mailalternateaddress"
Logical it's something like
unique_uri (ldap:///dc=basedn?mail?sub?) OR (ldap:///dc=basedn?mail?sub?)
Now I fail to correctly translate that to a valid configuration.
https://www.openldap.org/software/man.cgi?query=slapo-unique say "unique_uri <[strict ][ignore ]URI[URI...]...>"
with a formal definition of URI "ldap:///[base dn]?[attributes...]?scope[?filter]"
It also say "Multiple URIs may be specified within a domain, allowing complex selections of objects."
As the manpage doesn't give an example I tried:
unique_uri ldap:///dc=ldap?mailalternateaddress?sub ldap:///dc=ldap?mail?sub
slapd logs
5c445384 /etc/openldap/slapd.conf: line 149 (unique_uri ldap:///dc=ldap?mailalternateaddress?sub ldap:///dc=ldap?mail?sub)
-> slapd starts but uniqueness is not enforced
So I tried multiple versions:
To make it readable: uri1=ldap:///dc=ldap?mailalternateaddress?sub
uri2=ldap:///dc=ldap?mail?sub
unique_uri uri1 uri2
unique_uri uri1uri2
unique_uri uri1,uri2
unique_uri uri1, uri2
unique_uri "uri1 uri2"
unique_uri "uri1""uri2"
unique_uri "uri1","uri2"
unique_uri "uri1", "uri2"
Mostly slapd failed to start with an error "invalid ldap urilist"
If slapd started, the uniqueness wasn't enforced
One version (unique_uri "uri1 uri2") result in slapd consume 100% cpu time.
Anybody have a hint how to enforce uniqueness on multiple attributes?
Andreas
4 years, 8 months
lastbind module and missing forwarding updates
by David Magda
Hello,
So I'm looking at the code for the /lastbind/ module, and I see the
following:
> "MAY ( olcLastBindPrecision $ olcLastBindForwardUpdates) )",
https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/la...
However, when selecting various tagged releases
(OPENLDAP_REL_ENG_2_4_[37-47]) I do not see the code. It was committed in
October 2013:
https://github.com/openldap/openldap/commit/44e9bda0e42f40e0baf0a2c0ef733...
This would have been around the time of 2.4.37, but I don't see ITS#7721
mentioned in the release notes anywhere either, only ITS#772{0,2,3,5}:
https://www.openldap.org/software/release/changes.html
Is there a reason why this commit is in "master", but never made it to any
official release?
Regards,
David
4 years, 8 months
Shared memory error after reboot
by Marc Roos
I am getting this error after (re)booting, if I restart slapd it is
gone. I guess I can ignore this message because slapd will recover from
this eventually? Or do I need to give it a restart every time?
After reboot:
jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30
2018 23:14:27)
$#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap
-2.4.44/openldap-2.4.44/servers/slapd
Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504
searchbase="dc=backoffice,dc=local": no retry defined, using default
Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118
shmat: id 884736: unable to attach to shared system memory region:
Invalid argument
Jan 16 14:57:19 mail04 slapd[3285]: hdb_db_open: database
"dc=backoffice,dc=local": shared memory env open failed, assuming stale
env.
Jan 16 14:57:19 mail04 slapd[3285]: slapd starting
Jan 16 14:57:20 mail04 slapd[3285]: do_syncrep2: rid=504
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
After restart:
Jan 16 14:58:59 mail04 slapd[3285]: daemon: shutdown requested and
initiated.
Jan 16 14:58:59 mail04 slapd[3285]: slapd shutdown: waiting for 1
operations/tasks to finish
Jan 16 14:58:59 mail04 slapd[3285]: slapd stopped.
Jan 16 14:58:59 mail04 slapd[3402]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30
2018 23:14:27)
$#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap
-2.4.44/openldap-2.4.44/servers/slapd
Jan 16 14:58:59 mail04 slapd[3402]: syncrepl rid=504
searchbase="dc=backoffice,dc=local": no retry defined, using default
Jan 16 14:58:59 mail04 slapd[3404]: slapd starting
Jan 16 14:58:59 mail04 slapd[3404]: do_syncrep2: rid=504
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
openldap-2.4.44-20.el7.x86_64
openldap-clients-2.4.44-20.el7.x86_64
Linux mail04 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
CentOS Linux release 7.6.1810 (Core)
4 years, 8 months
