[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid



Russ Allbery wrote:
Howard Chu <hyc@symas.com> writes:

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.

Well, no, my line of reasoning is not based on this. My line of reasoning is based on the fact that a user who doesn't understand the full list of parameters that must be specified in their local configuration opens themselves to a security vulnerability that would allow an attacker to spoof NSS information by changing the trust parameters for their LDAP configuration so that the system would trust an LDAP server under the control of an attacker. This attack is very similar to the sorts of attacks that can be launched against NIS; avoiding it is one of the reasons why Stanford, at the least, moved away from NIS and towards LDAP for NSS information since remote LDAP servers can be authenticated.

"users" = sysadmins here. Sysadmins have a responsibility to understand what they're doing with their systems, that's what sysadmins do.


So, there's a couple of options that the NSS module should verify are set,
obviously (the URI and the two TLS certificate authority paths).  Probably
BASE and TLS_REQCERT as well.  Now, though, I'm not sure what the security
implications are of not setting several other ones.  From the
descriptions, I can't immediately rule out possible interference with the
system security policy via TLS_CALCHECK, TLS_CIPHER_SUITE, SASL_SECPROPS,
SASL_MECH, SASL_REALM, SASL_AUTHCID, SASL_AUTHZID, DEREF, and REFERRALS,
although for the most part I'd expect fiddling with them to fail.

That's a lot to verify is set, some of which many users will not *want* to
set.  Can you provide more information about exactly what parameters the
NSS module needs to provide to ensure that none of the information in a
local ldaprc file will be used?  I'm not sure that I can picture what the
code should look like to ensure this.

Have a look in _nss_ldap_init_config in nss_ldap/util.c (there's a similar function in pam_ldap.c)...


BASE generally isn't useful in nss_ldap since you must configure the SSDs for each of the maps that nss_ldap will use. Likewise for pam_ldap, since it just uses the passwd SSD. So setting it or ignoring it is irrelevant.

BINDDN/BINDPW - you can't set a bindpw in ldaprc. Omitting these settings means you're using anonymous. The worst thing that can happen is that someone specifies a BINDDN but again, since bindpw is missing, it will still be anonymous.

saslid - ignored unless you set usesasl. If you enable sasl without setting a saslid, it's possible for some arbitrary ID to be configured. But again, without a password, such a setting is usually useless. If you're using a mech like GSSAPI or EXTERNAL that doesn't use passwords, it may connect successfully, with that ID's privileges. Whether the ID can see the relevant info that pam/nss needs would determine what happens next.

rootbinddn/rootbindpw - obviously no such thing exists in ldap.conf/ldaprc.

version - hardcoded to LDAP_VERSION3, pam/nss setting will override anything in ldap.conf/ldaprc.
timelimit, bind_timelimit, ssl_on, referrals, restart - ditto


tls_checkpeer - this is a vulnerability, as the pam/nss default is to not set it and use the library default. Probably pam/nss should be patched to use an explicit setting here.

tls_cacertfile/cacertdir - generally one of these must be specified for TLS to work at all. If you omit these then yes some other trusted certs may get used. It may be legitimate to omit these settings if you have turned checkpeer off, but obviously that's an insecure configuration to begin with.

tls_ciphers - the default is ALL, so the only consequence of omitting this setting is that someone might set a more restrictive set of ciphers.

tls_cert / tls_key - if not specified, none is used. If left blank, at worst you'll get a client cert used where none was needed.

tls_randfile - ignored on Linux and any platform that provides /dev/urandom. On systems without it, it would be possible to point this at a source of constant numbers, thus allowing you to predict the keys of all TLS sessions.

sasl_secprops - it would be possible to specify weaker props if this value is not set.

The pam/nss config has no option to control CRL checking, so that can only come ldap.conf.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/