Since AI-driven "researchers" are submitting more bug reports these days in hopes of adding CVEs to their CVs, we're probably going to need to publish a more formalized security policy on the openldap.org web site. This is an example of what we're starting with. Feedback welcome.
Hi!
Some comments:
A crash, an abort, an assertion failure, or a hang is a **bug**, not a security issue.
So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not a security issue?
**LMDB trusts its own database files by contract.**
A long time Linux did trust filesystems as well, but some people managed to do bad things by providing manipulated filesystem images (e.g. ISOs). So if some deployment scenario would provide an LMDB image, and that image would cause some buffer overflow, resulting in execution of unwanted actions, wouldn't that be a security bug to care for?
In general I think the guidelines are even a bit too technical for the average user.
Kind regards, Ulrich Windl
-----Original Message----- From: Howard Chu hyc@symas.com Sent: Tuesday, August 11, 2026 6:11 PM To: OpenLDAP Technical openldap-technical@OpenLDAP.org Subject: [EXT] Security policy
Since AI-driven "researchers" are submitting more bug reports these days in hopes of adding CVEs to their CVs, we're probably going to need to publish a more formalized security policy on the openldap.org web site. This is an example of what we're starting with. Feedback welcome.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Windl, Ulrich wrote:
Hi!
Some comments:
A crash, an abort, an assertion failure, or a hang is a **bug**, not a security issue.
So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not a security issue?
It does not allow remote code execution, privilege escalation, or privileged data exfiltration. So no, it is not a security issue.
**LMDB trusts its own database files by contract.**
A long time Linux did trust filesystems as well, but some people managed to do bad things by providing manipulated filesystem images (e.g. ISOs). So if some deployment scenario would provide an LMDB image, and that image would cause some buffer overflow, resulting in execution of unwanted actions, wouldn't that be a security bug to care for?
ISO files are, by design, portable formats meant for public exchange. Thus they actually have a significant exposure, by design.
LMDB is an embedded database engine, its files are architecture-specific. It is non-portable by design. Its files are private data, owned by the applications that created them, not meant for public exchange. The security of the files is entirely the responsibility of the applications that created them.
The entire question is ludicrous - when was the last time anyone emailed a BerkeleyDB database file or made it publicly downloadable?
In general I think the guidelines are even a bit too technical for the average user.
The guidelines are aimed at security researchers, with the purpose of discouraging the filing of ordinary bug reports as security issues. Of course they must be technical.
Kind regards, Ulrich Windl
-----Original Message----- From: Howard Chu hyc@symas.com Sent: Tuesday, August 11, 2026 6:11 PM To: OpenLDAP Technical openldap-technical@OpenLDAP.org Subject: [EXT] Security policy
Since AI-driven "researchers" are submitting more bug reports these days in hopes of adding CVEs to their CVs, we're probably going to need to publish a more formalized security policy on the openldap.org web site. This is an example of what we're starting with. Feedback welcome.
On 2026-08-12 13:47, Howard Chu wrote:
Windl, Ulrich wrote:
So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not a security issue?
It does not allow remote code execution, privilege escalation, or privileged data exfiltration. So no, it is not a security issue.
That's an extraordinary position to take.
Remotely stopping code execution certainly gives the attacker something they did not have. Being able to remotely stop your systems from operating at will, with all the associated revenue loss and other impacts that may have may well allow an attacker to achieve their aims completely.
There are three impact categories for CVEs: confidentiality, integrity and availability. Are you really saying that ceding control over availability to an attacker is not a security issue? Being able to, say, shut down a rival phone company at will by killing their directory service seems like a security concern.
You asked for feedback, and I think you should reconsider this. A DoS is a security issue as far as most of the software industry is concerned. Less serious than RCE or LPE, but still of value to an attacker.
Cheers,
Brett A C Sheffield wrote:
On 2026-08-12 13:47, Howard Chu wrote:
Windl, Ulrich wrote:
So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not a security issue?
It does not allow remote code execution, privilege escalation, or privileged data exfiltration. So no, it is not a security issue.
That's an extraordinary position to take.
Remotely stopping code execution certainly gives the attacker something they did not have. Being able to remotely stop your systems from operating at will, with all the associated revenue loss and other impacts that may have may well allow an attacker to achieve their aims completely.
There are three impact categories for CVEs: confidentiality, integrity and availability. Are you really saying that ceding control over availability to an attacker is not a security issue? Being able to, say, shut down a rival phone company at will by killing their directory service seems like a security concern.
Realistically, no company exposes their directory infrastructure to the public Internet. There have been many DoS's via leftover asserts in the code thru the years, but none of these have ever been associated with reports of actual attacks.
You asked for feedback, and I think you should reconsider this. A DoS is a security issue as far as most of the software industry is concerned. Less serious than RCE or LPE, but still of value to an attacker.
Are we talking about the same software industry that thinks LLMs are the coolest thing ever? Arguments based on what the rest of the industry deems important aren't really convincing.
This has been the OpenLDAP Project policy since the beginning, in 1998. We care about data integrity and privacy first and foremost. You can't break the privacy of a downed server.
On 8/12/26 9:12 AM, Howard Chu wrote:
Realistically, no company exposes their directory infrastructure to the public Internet. There have been many DoS's via leftover asserts in the code thru the years, but none of these have ever been associated with reports of actual attacks.
I know of some universities that purposely do expose a partial DIT to the world, very deliberately, and reasonably. I would never recommend this, but some do this.
A good security team would not imagine DOS as possible from only the internet. Internal DOS, often of the friendly-fire sort, happens, and with it, often degradation of security infra. A well-built identity and PAM system will be engineered to be resilient in the face of an LDAP outage, but usually won't like one for very long.
It's trivial to overwhelm an OpenLDAP server with simple hardware and simple client script. I wish that would be less easy to do.
On Thu, Aug 13, 2026 at 08:36:01AM -0700, Chris Paul wrote:
On 8/12/26 9:12 AM, Howard Chu wrote:
Realistically, no company exposes their directory infrastructure to the public Internet. There have been many DoS's via leftover asserts in the code thru the years, but none of these have ever been associated with reports of actual attacks.
I know of some universities that purposely do expose a partial DIT to the world, very deliberately, and reasonably. I would never recommend this, but some do this.
I would say that's a reasonable deployment, but as you expose a limited fraction of the tree, those replicas should store only that "public" fraction and have no access to anything else.
A good security team would not imagine DOS as possible from only the internet. Internal DOS, often of the friendly-fire sort, happens, and with it, often degradation of security infra. A well-built identity and PAM system will be engineered to be resilient in the face of an LDAP outage, but usually won't like one for very long.
An accidental DoS vs. intentional. If there's intent, you can usually track it down to someone who originated it?
It's trivial to overwhelm an OpenLDAP server with simple hardware and simple client script. I wish that would be less easy to do.
Unfortunately for many admins an LDAP server is both an identity source (the cheap requests) and a database (the sort that you don't give random clients access to). Still, there is a lot you can do to limit that, e.g. (unchecked) limits, with 2.7 even exop/control restrictions and only let some accounts access the expensive parts of the protocol/DB.
Or what other scenarios do you have in mind above?
Regards,
On 8/24/26 1:44 AM, Ondřej Kuzník wrote:
I would say that's a reasonable deployment, but as you expose a limited fraction of the tree, those replicas should store only that "public" fraction and have no access to anything else.
The ones I know who do, do this.
An accidental DoS vs. intentional. If there's intent, you can usually track it down to someone who originated it?
Yup, for sure although I've "handled" a friendly DOS before by setting loglevel to 0, which greatly increases the load a server can handle; then analyzing cn=connections,cn=monitor saved the day.
Unfortunately for many admins an LDAP server is both an identity source (the cheap requests) and a database (the sort that you don't give random clients access to). Still, there is a lot you can do to limit that, e.g. (unchecked) limits, with 2.7 even exop/control restrictions and only let some accounts access the expensive parts of the protocol/DB.
Yup, it's not that OpenLDAP has no guards. Limits do a lot, but they don't prevent multiple connections from the same IP, for example.
Or what other scenarios do you have in mind above?
Some configurations that would be worth considering:
* conn_max_per_ip * conn_max_per_ip_auth * conn_max_per_anon * conn_max_per_authc
Yes, firewalls can do some of this.
I should mention that I offer this just as room for improvement. OpenLDAP is extremely good, very resilient software. I recommend it to anyone who asks me for LDAP software. I don't know of other LDAP services that can handle as much load as OpenLDAP. Yet it would be better if it could impose more limits to protect itself from intentional or unintentional overuse.
On Wed, Aug 12, 2026 at 03:15:52PM +0200, Brett A C Sheffield wrote:
On 2026-08-12 13:47, Howard Chu wrote:
Windl, Ulrich wrote:
So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not a security issue?
It does not allow remote code execution, privilege escalation, or privileged data exfiltration. So no, it is not a security issue.
That's an extraordinary position to take.
Remotely stopping code execution certainly gives the attacker something they did not have. Being able to remotely stop your systems from operating at will, with all the associated revenue loss and other impacts that may have may well allow an attacker to achieve their aims completely.
There are three impact categories for CVEs: confidentiality, integrity and availability. Are you really saying that ceding control over availability to an attacker is not a security issue? Being able to, say, shut down a rival phone company at will by killing their directory service seems like a security concern.
You asked for feedback, and I think you should reconsider this. A DoS is a security issue as far as most of the software industry is concerned. Less serious than RCE or LPE, but still of value to an attacker.
Hi Brett, I think you're confusing a critical bug and a vulnerability. An anonymous user being able to bring a server down is clearly the former but not latter, just like a hypothetical critical replication bug which clearly needs no CVE. We're not going to stop people from flagging it as private as mentioned in the preamble.
I agree that a tweak to clarify this is worth making. There might be a way to adjust the description that outlines that distinction yet does not suggest we encourage the perverse incentives of finding literally any bug and insisting it is a vulnerability which is really happening. If you have a suggestion, we're more than happy to adjust, that's the reason we proposed this here first before it lands on the website and maybe repo at some point.
Regards,
On 2026-08-13 11:58, Ondřej Kuzník wrote:
I think you're confusing a critical bug and a vulnerability.
No confusion, just a difference of opinion. A bug is a bug. Whether or not that is considered a security vulnerability generally depends on whether that bug is useful to an attacker.
Being able to crash a service at will can certainly have value to an attacker. That's why one of the three "impact" categories for CVEs is Availability. I've read hundreds of CVEs this year where availability is the only impact. These are handled as security bugs by downstream distributions which package your software. They have CVE numbers. They are subject to disclosure embargos. They are treated as security updates by commercial clients, who will incur reporting obligations under the EU's Cyber Resilience Act from September this year.
The OpenLDAP Project's position appears to be that ceding control of availability to an attacker is not a security issue, just a bug. That's fine. That position puts you at odds with most of the software industry (even those of us who do not think LLMs are cool), which is why I raised it. There is value in standards, and taking a position that is at odds with downstreams, customers and emerging regulations just creates more work for the ecosystem around your project. A DoS will need a CVE even if you decide it is actually a banana.
For a service like OpenLDAP, which is depended on for SSO, logging, recording billing data, call routing etc. it doesn't take much imagination to come up with scenarios where the resulting loss of availability can have value to an attacker.
I agree that a tweak to clarify this is worth making. There might be a way to adjust the description that outlines that distinction yet does not suggest we encourage the perverse incentives of finding literally any bug and insisting it is a vulnerability which is really happening. If you have a suggestion, we're more than happy to adjust, that's the reason we proposed this here first before it lands on the website and maybe repo at some point.
The clarification regarding LMDB trusting its files is useful and gives us something to point at when pushing back against projects (like pylmdb) making unwise assumptions about LMDB. eg. https://bugs.gentoo.org/971352
Hi!
Just two points: If someone overloads a server causing DoS, then it's most likely not a security bug, but if someone could send some magic packet that would permanentlyx block an LDAP service thread, that would definitely be a security bug (IMHO), See one of the latest OpenSSL bugs (HollowByte, AFAIR).
Even companies not exposing their services to the public Internet are worried with DoS attacks, assuming that even their staff could be a potential adversary. Paranoid, maybe, but real.
Kind regards, Ulrich Windl
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Thursday, August 13, 2026 11:58 AM To: Brett A C Sheffield bacs@librecast.net Cc: OpenLDAP Technical openldap-technical@openldap.org Subject: [EXT] Re: [EXT] Security policy
Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.
On Wed, Aug 12, 2026 at 03:15:52PM +0200, Brett A C Sheffield wrote:
On 2026-08-12 13:47, Howard Chu wrote:
Windl, Ulrich wrote:
So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not
a security issue?
It does not allow remote code execution, privilege escalation, or privileged data exfiltration. So no, it is not a security issue.
That's an extraordinary position to take.
Remotely stopping code execution certainly gives the attacker something
they did
not have. Being able to remotely stop your systems from operating at will,
with
all the associated revenue loss and other impacts that may have may well
allow
an attacker to achieve their aims completely.
There are three impact categories for CVEs: confidentiality, integrity and availability. Are you really saying that ceding control over availability to an attacker is not a security issue? Being able to, say, shut down a rival phone company at will by killing their directory service seems like a security concern.
You asked for feedback, and I think you should reconsider this. A DoS is a security issue as far as most of the software industry is concerned. Less serious than RCE or LPE, but still of value to an attacker.
Hi Brett, I think you're confusing a critical bug and a vulnerability. An anonymous user being able to bring a server down is clearly the former but not latter, just like a hypothetical critical replication bug which clearly needs no CVE. We're not going to stop people from flagging it as private as mentioned in the preamble.
I agree that a tweak to clarify this is worth making. There might be a way to adjust the description that outlines that distinction yet does not suggest we encourage the perverse incentives of finding literally any bug and insisting it is a vulnerability which is really happening. If you have a suggestion, we're more than happy to adjust, that's the reason we proposed this here first before it lands on the website and maybe repo at some point.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
openldap-technical@openldap.org
-
Brett A C Sheffield -
Chris Paul -
Howard Chu -
Ondřej Kuzník -
Windl, Ulrich