[email protected] wrote: > Hi, > > Anyway, I consider this issue a denial of service vulnerability and OpenLDAP > 2.4.45 will not be used for production here. > > The only major change in configuration was switching from hdb to mdb, so I > will have to check whether mdb may be the cause of this issue.
You never answered Quanah's questions about your config. Are you actually running on a server with 4096 CPUs? If not, why is your maxreaders set to 4096? > > Regards Juergen > > -----Original Message----- > From: Quanah Gibson-Mount [mailto:[email protected]] > Sent: Mittwoch, 30. Januar 2019 15:53 > To: Sprenger Jürgen, INI-ONE-CIS-SDI-HES <[email protected]>; > [email protected] > Subject: Re: OpenLDAP 2.4.45 possible denial of service vulnerability? > > --On Wednesday, January 30, 2019 9:43 AM +0000 [email protected] > wrote: > >> 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. > > Solaris 11.4 is out (just to note). And the latest OpenLDAP release is > 2.4.47 (just to note). > >> tool-threads 8 > > A tool-threads setting > 2 is ignored with back-mdb. > >> maxreaders 4096 > > This is an extremely large value (default is 126). Are you sure you need > this bumped so high? > >> searchstack 64 > > Similarly here. > >> 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. > > I'd estimate that your ability to get a useful response from either is near > zero. If you have an enterprise operation that needs support for OpenLDAP > you may want to look at Symas' enterprise OpenLDAP builds (Symas Gold). We > provide builds and support for Solaris 11. > >> To avoid performance issues loglevel is now "none stats sync" but can >> be changed for some time to track down the cause. > > You could just do "stats sync", not really a reason to leave "none" in the > list. > > Generally if you hit an issue such as this, you would want to provde a full > backtrace of the slapd process from a utility such as GDB. > > Warm regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
