[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: local authentication spoofing using libnss-ldap



On 24/12/2011 16:15, Arthur de Jong wrote:
On Thu, 2011-12-22 at 17:01 +0100, Yann Autissier wrote:
I am using the libnss-ldap and libpam-ldap packages with default
configuration.

NSS is configured to allow passwd and group resolution over ldap.

user@host:~$ cat /etc/nsswitch.conf
passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

If a user account exists in local /etc/passwd and in the ldap
database, the user can authenticate with both passwords, but is always
logged in as the local user.

Most *nix systems don't properly handle the cases where either the
username or the numeric userid is not unique (e.g. nscd is known to get
confused). So having a the "same" user in LDAP and in flat files is a
configuration problem.

useradd throws an error when a user account already exists in ldap, but some insertions may be done in the directory otherwise.


I can create a ldap account named 'root', with a weak password and uid
12345,  then su - on the system and log in as root with the weak
password, and get uid 0.

You could have a look at libnss-ldapd and libpam-ldapd (note the extra d
at the end). The PAM module has a minimum_uid option (defaults to 1000)
which avoids this problem. The 0.8 version of libnss-ldapd also provides
some filtering with the nss_min_uid option (not enabled by default).

This most likely protects against the case you described. Note however
that you have to put some trust in the LDAP server to provide correct
information.


Yes, the minimum_uid option in pam configuration prevents this authentication issue for the range defined. The nss_min_uid is not taken into account on debian squeeze version of libnss-ldap and libpam-ldap, nor libnss-ldapd and libpam-ldapd.

I understand that users should not be allowed to change their uidNumber in the directory, and that we should not be able to create an account if the username already exists in another nss db.

Thanks,

--
Yann


Reply to: