[Pkg-openldap-devel] Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid

[Howard Chu]

Russ Allbery wrote:
> Howard Chu <hyc at 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/