[Date Prev][Date Next]
Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
Russ Allbery wrote:
Howard Chu <firstname.lastname@example.org> 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
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
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
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
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/