Re: local authentication spoofing using libnss-ldap
On 03/01/2012 04:39, Mike Mestnik wrote:
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
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.
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
mapping from UID to name. And it does it in order specified in
if you want to see what name UID=12345 maps to, the system (in presented
configuration) first tries to look into /etc/passwd, then checks the
database for entry with apropriate attribute with the value of 12345
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.
It can be used to give access to a specific account uid with another
username/password. It's the same behavior here, but with the same username and
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
I will import all my /etc/passwd in the ldap directory, and double check that
username is unique in the user creation proccess.