Russ Allbery wrote: > I tried to convince upstream that this was a security concern and got > yelled at for my trouble until I gave up (although to be fair, upstream > did agree at least that reading files out of the current working directory > was a broken idea and they wouldn't do it if they were starting from > scratch now, but they didn't want to change the existing code). As I > recall, the theory was that any software that cared about security needed > to override the library defaults anyway so it wouldn't matter if the > library read an untrusted initialization file, and I think I verified that > and that is indeed correct. (Of course, that doesn't help against > segfaults in the config file parser.) The NSS module got all the > necessary initializations the last time this came up, which addressed the > immediate concerns at the time the bug was raised, so nothing further > happened with the Debian OpenLDAP package. > In my case, it looks like the NSS module is getting its certificates based on the defaults in $HOME/.ldaprc. I expect this, because I have the certificates configured in /etc/ldap/ldap.conf and nowhere else. This is presumable why it is segfaulting, because it is picking up the wrong certificates. This in turn would mean if somebody was able to interfere somehow with the network, they could trick sudo into authenticating against the wrong ldap server.
Sure, I could override all the defaults in /etc/ldap.conf (config file used by ldap-nss and ldap-pam), but this strikes me as (a) unnecessarily duplication of config settings in /etc/ldap.conf and /etc/ldap/ldap.conf and (b) risky because I might miss a config setting that needs to be overridden. It also doesn't appear to be documented anywhere. In fact the comments in /etc/ldap.conf would suggest it is OK to use the LDAP defaults: # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is to use libldap's default behavior, which can be configured in # /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for # OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes". #tls_checkpeer yes > The problem with just removing this code in the library is that it's also > how ldapsearch and friends get their defaults, which is actively used and > will break people's scripts if it goes away. > On my computers I would rather break this functionality, which I hardly ever use anyway (and on the one time I did use it caused random programs to segfault when I forgot about it several years later). Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
