[Impact]
Linux clients that use ldap authentication with nslcd and a long pam_authz_search filter will see authentication fail silently
$ lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10
version:
nss-pam-ldapd-0.7.13
expected:
Logging to indicate that the max filter length had been exceeded.
actual:
authentication fails silently
workaround:
Increase max filter length. char_filter_buffer in pam.c can be increased to 4096 bytes allowing for a longer search filter
[Test Case]
reproduction steps:
modify entry for 127.0.1.1 in /etc/hosts so the example.com dc is used by slapd
EX:
x.x.x.x server1
change to:
x.x.x.x server1.example.com server1
apt-get install nslcd # set search base "dc=example,dc=com". then select all for services use ldap lookups when configuring libnss-ldapd.
apt-get install slapd
dpkg-reconfigure slapd # dns name "example.com"
apt-get install migrationtools
turn on ldap authentication using pam-auth-update
stop nslcd and slapd. We'll start them in debug mode
/etc/init.d/nslcd stop
/etc/init.d/slapd stop
migrate users to ldap. edit /etc/migrationtools/migrate_common.ph and change:
$DEFAULT_MAIL_DOMAIN = "example.com";
$DEFAULT_BASE = "dc=example,dc=com";
then run commands to create ldif exports of group and passwd
/usr/share/migrationtools/migrate_group.pl /etc/group ~/group.ldif
/usr/share/migrationtools/migrate_passwd.pl /etc/passwd ~/passwd.ldif
edit ~/people_group.ldif adding contents:
dn: ou=People, dc=example, dc=com
ou: People
objectclass: organizationalUnit
dn: ou=Group, dc=example, dc=com
ou: Group
objectclass: organizationalUnit
import data into ldap:
ldapadd -x -W -D "cn=admin,dc=example,dc=com" -f ~/people_group.ldif
ldapadd -x -W -D "cn=admin,dc=example,dc=com" -f ~/group.ldif
ldapadd -x -W -D "cn=admin,dc=example,dc=com" -f ~/passwd.ldif
edit /etc/nslcd.conf adding pam_authz_search filter
pam_authz_search (&(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount)(objectClass=posixAccount))
open 2 new terminals and become root
in one terminal run nslcd in debug mode:
nslcd -d
in second terminal run slapd in debug mode:
slapd -d -1
in your original terminal attempt to sudo to a user other than root and watch the debug output in the slapd and nslcd terminals:
sudo su ubuntu
look for output in nslcd terminal "DEBUG: trying pam_authz_search" in nslcd terminal indicating filter is being used
increase search string beyond 1024 buffer and note that we're no longer seeing "Trying pam_authz_search" in the nslcd output and that authentication fails silently
[Regression Potential]
This just increases the buffer size from 1024 to 4096, it is already applied in Quantal, and this SRU simply increases this buffer size.
This patch increases the filter size per the bug report.
The latest SVN checkout of the code shows that this would need to be an upstream patch.