Re: local authentication spoofing using libnss-ldap
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.
>>>
>>> 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
>> 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 UID=12345 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.
>
>
Reply to: