[Bug 2475] Login failure when PasswordAuthentication, ChallengeResponseAuthentication, and PermitEmptyPasswords are all enabled

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2475

Peter Urbanec <bugzilla.mindrot.org at urbanec.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla.mindrot.org at urbane
                   |                            |c.net

--- Comment #2 from Peter Urbanec <bugzilla.mindrot.org at urbanec.net> ---
I have spent some time looking at this issue from the Linux PAM stack
end. It looks like the problem is actually caused by openssh calling
PAM from different threads/processes.

Here is the rough sequence of what happens, with the thread id inside
{} at the start of each line:

{12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(108)]
called.
{12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(176)]
user=root, password=[]
{12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)]
recording return code for next time [7]
{12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)]
done. [Authentication failure]
{12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(108)]
called.
{12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(176)]
user=root, password=[1]
{12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)]
recording return code for next time [0]
{12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)]
done. [Success]
{12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_acct.c:pam_sm_acct_mgmt(196)]
called.
{12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_acct.c:pam_sm_acct_mgmt(202)]
user = `root'
{12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_acct.c:pam_sm_acct_mgmt(307)]
all done
{12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_setcred(203)]
called.
{12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_setcred(209)]
recovering return code from auth call
{12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_setcred(217)]
recovered data indicates that old retval was 7

This translates to:

Thread 1 tries to authenticate with empty password
This fails and the failure is cached in thread 1 context
Thread 2 tries to authenticate again, this time with the password that
the user supplied
This succeeds and the success is cached in thread 2 context
Thread 1 tries to set credentials, which uses the cached failure from
thread 1

The call to pam_sm_setcred() should have come from the same thread that
performed the successful call to pam_sm_authenticate()

It looks like thread 2 has been forked from thread 1, because when it's
called, it knows about the previous auth failure and it correctly
replaces the previous (failure) return code with the new (success)
return code. However, the parent process can never see this updated
result code and instead only sees the previous failure.

I have not had the chance to explore the openssh code yet, but it looks
like the kind of thing that PrivSep would be involved in.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.