oss-security - Re: CVE request -- ucd-snmp / net-snmp, libnss-ldapd / nss

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / NEWS community lists Wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [month] [year] [list]

Date: Tue, 24 Mar 2009 20:19:52 -0600
From: Vincent Danen <vdanen@...hat.com>
To: oss-security@...ts.openwall.com
Cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE request -- ucd-snmp / net-snmp,
	libnss-ldapd / nss_ldap

* [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

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.