oss-sec mailing list archives

Re: CVE request -- ucd-snmp / net-snmp, libnss-ldapd / nss_ldap


From: Vincent Danen <vdanen () redhat com>
Date: Tue, 24 Mar 2009 20:19:52 -0600

* [2009-03-24 21:05:49 -0400] Steven M. Christey wrote:

>2, libnss-ldapd / nss_ldap: LDAP service configuration file
>                                 shipped with world readable permissions
>   References:
>   https://bugzilla.redhat.com/show_bug.cgi?id=491623
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520476

On a side note, this is pretty specific to libnss-ldapd and not so much
nss_ldap.

So, the various bug reports and followups list:

 libnss-ldapd
 nss_ldap
 nss-ldapd
 openldap

Which package is actually affected and what versions might they be?

nss-ldapd is the name of the upstream package.  I suppose Debian and
others may package it with a package name of libnss-ldapd.

nss-ldapd is a fork of nss_ldap... I don't know enough to say how much
it differs, but for nss_ldap at least, /etc/ldap.conf should be
world-readable (or at least typically is, with no real exposure since
using non-anonymous binds to LDAP would be unusual -- at least from
everything I've seen and done with LDAP authentication).

/etc/ldap.conf has nothing to do with openldap and while the filename,
and probably file contents are the same, it sounds like libnss-ldap may
require more protection and/or be meant to run with a protected
configuration file.

It also, and someone correct me if I'm wrong, be due to the debian
package allowing someone to specify a bindpw at install and then not
protecting the file contents if someone does specify a bindpw.  With
RHEL and Fedora, there are no mechanisms to ask a user for a bindpw
(because it is not typical), so we would expect that an admin who puts a
bindpw in there for a user that is meant to be protected (i.e. something
other than an unprivileged user that suits the criteria for anonymous
binds for the purpose of obtaining certain non-privileged user
information), would also adequately protect the file when manually
setting the password.

And, if that is the case, then I would argue this is a debconf-specific
issue for this package than a general nss-ldapd-specific issue.

In fact, if you look here:

http://ch.tudelft.nl/~arthur/nss-ldapd/news.html#20090322

you'll see that this is noted as a "security problem in ... the Debian
package configuration".

Use CVE-2009-1073, to be filled in once I have some more detail.

--
Vincent Danen / Red Hat Security Response Team

Current thread: