local authentication spoofing using libnss-ldap

W dniu 2011-12-22 17:01, Yann Autissier pisze:

Hi List,

I am using the libnss-ldap and libpam-ldap packages with default
configuration.

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

:~$ 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.

It seems to mee that nss should resolve the correct uid.

I'm not sure what you mean by 'the correct uid'. NSS is responsible only
for mapping from UID to name. And it does it in order specified in
nsswitch.conf. So if you want to see what name UID345 maps to, the
system (in presented configuration) first tries to look into
/etc/passwd, then checks the ldap database for entry with apropriate
attribute with the value of 12345 (don't remember ATM which attribute it
is by default).

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.

It's not debian related, but I would like to know if this is a
misconfiguration.

Again, it has nothing to do with NSS. I suppose (sorry, don't have
a box with default config anywhere near) it can be caused by PAM stack
misconfiguration where pam tries to authenticate against local users
database and then, when it fails, tries again with the same password
against LDAP. If you did authentication the other way around - first
checking in LDAP, and only then in local file, you should be OK
(remember about restricting UID range in pam_ldap).

As I mentioned, I don't have a way to confirm this on a live box, so
please correct me if I'm wrong.


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

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.

:~$ 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.

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.






To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

On 22/12/2011 18:02, Mariusz Kruk wrote:

W dniu 2011-12-22 17:01, Yann Autissier pisze:

I am using the libnss-ldap and libpam-ldap packages with default
configuration.

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

:~$ 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.

It seems to me that nss should resolve the correct uid.

I'm not sure what you mean by 'the correct uid'. NSS is responsible only for
mapping from UID to name. And it does it in order specified in nsswitch.conf. So
if you want to see what name UID345 maps to, the system (in presented
configuration) first tries to look into /etc/passwd, then checks the ldap
database for entry with apropriate attribute with the value of 12345 (don't
remember ATM which attribute it is by default).

I think that NSS and PAM are working with username, and when authentication
succeeds in libpam-ldap, it returns success, then NSS resolves the username with
the first uid found in 'compat ldap'.

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.

It's not debian related, but I would like to know if this is a
misconfiguration.

Again, it has nothing to do with NSS. I suppose (sorry, don't have
a box with default config anywhere near) it can be caused by PAM stack
misconfiguration where pam tries to authenticate against local users database
and then, when it fails, tries again with the same password against LDAP. If you
did authentication the other way around - first checking in LDAP, and only then
in local file, you should be OK (remember about restricting UID range in pam_ldap).

As I mentioned, I don't have a way to confirm this on a live box, so please
correct me if I'm wrong.

Swapping pam_unix and pam_ldap in /etc/pam.d/common-* does not seem to solve the
problem.

Swapping to 'passwd: ldap files' in /etc/nsswitch.conf reverse the problem, as I
cannot get uid=0 anymore.


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

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.

:~$ 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


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

On 01/02/12 15:52, Yann Autissier wrote:

On 22/12/2011 18:02, Mariusz Kruk wrote:

W dniu 2011-12-22 17:01, Yann Autissier pisze:

I am using the libnss-ldap and libpam-ldap packages with default
configuration.

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

:~$ 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.

It seems to me that nss should resolve the correct uid.

I'm not sure what you mean by 'the correct uid'. NSS is responsible
only for
mapping from UID to name. And it does it in order specified in
nsswitch.conf. So
if you want to see what name UID345 maps to, the system (in presented
configuration) first tries to look into /etc/passwd, then checks the
ldap
database for entry with apropriate attribute with the value of 12345
(don't
remember ATM which attribute it is by default).

I think that NSS and PAM are working with username, and when
authentication succeeds in libpam-ldap, it returns success, then NSS
resolves the username with the first uid found in 'compat ldap'.

How would toor work then: It's a UID 0 account with another shell.
This gives root/toor a better chance of being able to login if bash or
csh needed to be fixed, having two shells available for root login can
be essential in some circumstances, like library upgrades gone wrong.

http://en.wikipedia.org/wiki/Toor_(Unix)

The Username and UID must be carried through together throughout the
authentication to avoid these security risks. That is when the username
or UID is supplied a lookup must be done to resolve the other, however
this should only be done once and after wards both should be canonical
as a set... any further attermpt to re-resolve one or the other would
lead to problems like those explained here or worse.

That said for two accounts both labeled root would seam to cause
problems, eventually.

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.

It's not debian related, but I would like to know if this is a
misconfiguration.

Again, it has nothing to do with NSS. I suppose (sorry, don't have
a box with default config anywhere near) it can be caused by PAM stack
misconfiguration where pam tries to authenticate against local users
database
and then, when it fails, tries again with the same password against
LDAP. If you
did authentication the other way around - first checking in LDAP, and
only then
in local file, you should be OK (remember about restricting UID range
in pam_ldap).

As I mentioned, I don't have a way to confirm this on a live box, so
please
correct me if I'm wrong.

Swapping pam_unix and pam_ldap in /etc/pam.d/common-* does not seem to
solve the problem.

Swapping to 'passwd: ldap files' in /etc/nsswitch.conf reverse the
problem, as I cannot get uid=0 anymore.

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/