NetBSD Problem Report #43160

From www@NetBSD.org  Wed Apr 14 00:38:08 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 43C4263C52A
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 14 Apr 2010 00:38:08 +0000 (UTC)
Message-Id: <20100414003807.C131063BCF6@www.NetBSD.org>
Date: Wed, 14 Apr 2010 00:38:07 +0000 (UTC)
From: aaron.turner@equinix.com
Reply-To: aaron.turner@equinix.com
To: gnats-bugs@NetBSD.org
Subject: nss_ldap 
X-Send-Pr-Version: www-1.0

>Number:         43160
>Category:       security
>Synopsis:       nss_ldap
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    security-officer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 14 00:40:00 +0000 2010
>Last-Modified:  Sun Apr 25 21:55:00 +0000 2010
>Originator:     Aaron Turner
>Release:        5.0.1
>Organization:
Equinix
>Environment:
NetBSD edrs-netbsd-i386 5.0.1 NetBSD 5.0.1 (GENERIC.TCP-MD5) #0: Tue Feb 23 17:02:35 PST 2010  mdo@edrs-netbsd-i386:/usr/objdir/sys/arch/i386/compile/GENERIC.TCP-MD5 i386
>Description:
Configured our NetBSD box to do LDAP queries for user/group information via /etc/nsswitch.conf.  The LDAP server (OpenLDAP 2.3.43 on CentOS 5) requires all communication done via SSL.  What I've found is during user login (via ssh), the nss_ldap module (compiled via pkgsrc, version 260) connects and starts making queries, but then sends a SSL message with a bad Record MAC.  The LDAP server then closes the connection.  The login then hangs while the nss_ldap module times out.

I'm using this with pam_ldap for authentication as well.

Comparing the decrypted SSL LDAP session (i have the ldap server's private key) to a non-ssl login session, it *appears* to send the invalid SSL Record MAC when doing the second group query where the filter = (&(objectClass=posixGroup)(memberUid=XXXXXXXX)) and attributes = gidNumber.  This seems to be a repeated query based on the non-ssl pcap trace, so not sure why it works the first time, but not the second time.

* I say appears, because Wireshark won't decode the payload of the query because of the bad Record MAC.
>How-To-Repeat:
----- /etc/nsswitch.conf:
group: files ldap
passwd: files ldap

-----  /usr/pkg/etc/ldap.conf:
uri ldaps://your.ldap.server/
ssl on
tls_checkpeer yes
tls_cacertfile  /etc/pki/company_internal_ca.pem
base dc=company,dc=com
ldap_version 3
rootbinddn cn=Manager,dc=company,dc=com
scope sub
timelimit 15
bind_timelimit 15
#idle_timelimit 3600
pam_filter objectClass=posixAccount
# Change this to match your Machine entry
pam_groupdn cn=netbsd,ou=Machines,dc=company,dc=com
pam_member_attribute member
pam_password exop
nss_base_passwd     ou=Users,dc=company,dc=com?one
nss_base_shadow     ou=Users,dc=company,dc=com?one
nss_base_group      ou=Groups,dc=company,dc=com?one
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm

----- Actions:
Login remotely via ssh using a user in LDAP but not in /etc/passwd.  If you run wireshark, you'll see the server send an Alert with level Fatal in response to one of the queries.
>Fix:
N/A

>Audit-Trail:
From: "NetBSD's security officer tracking via RT" <security-replies@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: [NetBSD.org #29959] AutoReply: security/43160: nss_ldap  
Date: Sun, 25 Apr 2010 21:53:19 +0000

 Greetings,

 This message has been automatically generated in response to the
 creation of a trouble ticket regarding:
 	"security/43160: nss_ldap ", 
 a summary of which appears below.

 There is no need to reply to this message right now.  Your ticket has been
 assigned an ID of [NetBSD.org #29959].

 Please include the string:

          [NetBSD.org #29959]

 in the subject line of all future correspondence about this issue. To do so, 
 you may reply to this message.

                         Thank you,
                         security-replies@rt.NetBSD.org

 -------------------------------------------------------------------------
 >Number:         43160
 >Category:       security
 >Synopsis:       nss_ldap
 >Confidential:   no
 >Severity:       serious
 >Priority:       medium
 >Responsible:    security-officer
 >State:          open
 >Class:          sw-bug
 >Submitter-Id:   net
 >Arrival-Date:   Wed Apr 14 00:40:00 +0000 2010
 >Originator:     Aaron Turner
 >Release:        5.0.1
 >Organization:
 Equinix
 >Environment:
 NetBSD edrs-netbsd-i386 5.0.1 NetBSD 5.0.1 (GENERIC.TCP-MD5) #0: Tue Feb 23 17:02:35 PST 2010  mdo@edrs-netbsd-i386:/usr/objdir/sys/arch/i386/compile/GENERIC.TCP-MD5 i386
 >Description:
 Configured our NetBSD box to do LDAP queries for user/group information via /etc/nsswitch.conf.  The LDAP server (OpenLDAP 2.3.43 on CentOS 5) requires all communication done via SSL.  What I've found is during user login (via ssh), the nss_ldap module (compiled via pkgsrc, version 260) connects and starts making queries, but then sends a SSL message with a bad Record MAC.  The LDAP server then closes the connection.  The login then hangs while the nss_ldap module times out.

 I'm using this with pam_ldap for authentication as well.

 Comparing the decrypted SSL LDAP session (i have the ldap server's private key) to a non-ssl login session, it *appears* to send the invalid SSL Record MAC when doing the second group query where the filter = (&(objectClass=posixGroup)(memberUid=XXXXXXXX)) and attributes = gidNumber.  This seems to be a repeated query based on the non-ssl pcap trace, so not sure why it works the first time, but not the second time.

 * I say appears, because Wireshark won't decode the payload of the query because of the bad Record MAC.
 >How-To-Repeat:
 ----- /etc/nsswitch.conf:
 group: files ldap
 passwd: files ldap

 -----  /usr/pkg/etc/ldap.conf:
 uri ldaps://your.ldap.server/
 ssl on
 tls_checkpeer yes
 tls_cacertfile  /etc/pki/company_internal_ca.pem
 base dc=company,dc=com
 ldap_version 3
 rootbinddn cn=Manager,dc=company,dc=com
 scope sub
 timelimit 15
 bind_timelimit 15
 #idle_timelimit 3600
 pam_filter objectClass=posixAccount
 # Change this to match your Machine entry
 pam_groupdn cn=netbsd,ou=Machines,dc=company,dc=com
 pam_member_attribute member
 pam_password exop
 nss_base_passwd     ou=Users,dc=company,dc=com?one
 nss_base_shadow     ou=Users,dc=company,dc=com?one
 nss_base_group      ou=Groups,dc=company,dc=com?one
 nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm

 ----- Actions:
 Login remotely via ssh using a user in LDAP but not in /etc/passwd.  If you run wireshark, you'll see the server send an Alert with level Fatal in response to one of the queries.
 >Fix:
 N/A

Home	PR Database Search