[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE request -- ucd-snmp / net-snmp,
From:       Vincent Danen <vdanen () redhat ! com>
Date:       2009-03-25 2:19:52
Message-ID: 20090325021952.GJ4170 () redhat ! com
[Download RAW message or body]

* [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 
[prev in list] [next in list] [prev in thread] [next in thread]