Russ Allbery wrote:
In the meantime, the patch isn't exactly something I'd want to take upstream either, but it at least addresses the most obvious problem, and more problematically I don't see a better way of addressing it other than saying "well, anyone without a system-wide ldap.conf loses." And I wouldn't be comfortable trying to defend that position.
I suppose another possible workaround specific to the NSS module (and probably the PAM module as well) would be to proactively check whether there's a system-wide ldap.conf file and fail immediately if there isn't. That leaves the problem open for other setuid uses of the LDAP libraries, but I don't expect there are a lot of those and what ones there may be are more likely to be able to use the LDAPNOINIT flag.
This whole line of reasoning appears to be based on the assumption that OpenLDAP's ldap.conf and pam/nss_ldap's ldap.conf are equivalent, which is false. pam/nss_ldap use their own config file, which is not the OpenLDAP default config file. A properly configured pam/nss_ldap fully specifies all of the options that pam/nss needs. In this situation, the presence of other ldap.conf and ldaprc files is irrelevant, since they can only be used to supply defaults when the calling application does not specify particular arguments. E.g., the URI in <openldap>/ldap.conf will only be used by libldap if the calling API doesn't specify a URI. DNS poisoning and other such bizarre attacks of course can apply regardless, but that's completely orthogonal to the question of where the URI was specified.
Apps that intend to use libldap and intend to be installed setuid have the responsibility to insure that they are properly and adequately configured, such that arbitrary defaults outside the app's awareness are never used. That's just common sense.