[Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation

thierry bordaz tbordaz at redhat.com
Thu Nov 6 13:19:04 UTC 2014


On 11/06/2014 02:14 PM, Alexander Bokovoy wrote:
> On Thu, 06 Nov 2014, thierry bordaz wrote:
>> On 11/06/2014 12:35 PM, Alexander Bokovoy wrote:
>>> On Thu, 06 Nov 2014, thierry bordaz wrote:
>>>> On 11/05/2014 09:14 PM, Nathaniel McCallum wrote:
>>>>> Before this patch users could log in using only the OTP value. This
>>>>> arose because ipapwd_authentication() successfully determined that
>>>>> an empty password was invalid, but 389 itself would see this as an
>>>>> anonymous bind. An anonymous bind would never even get this far in
>>>>> this code, so we simply deny requests with empty passwords.
>>>>>
>>>>> This patch resolves CVE-2014-7828.
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/4690
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-devel mailing list
>>>>> Freeipa-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>> Hello Nathaniel,
>>>>
>>>>  With the DS flag 'nsslapd-allow-unauthenticated-binds', customer
>>>>  have the ability to allows unauthenticated binds and connections.
>>>>  With the fix, a ldapclient bind containing only OTP part will fail
>>>>  even if the flag was set.
>>> By definition of nsslapd-allow-unauthenticated-binds, it requires a 
>>> BIND
>>> with name but no password. Specifying OTP value will make password
>>> non-empty and thus failing unauthenticated bind request definition.
>>
>> Hello Alexander,
>>
>>   I agree that regarding the RFC, there is unauthenticated bind when
>>   the password is empty. The question is when the test of empty
>>   password should be done.
>>   On DS implementation, the toggle
>>   ('nsslapd-allow-unauthenticated-binds') is enforced in frontend when
>>   the password is untouched (and so not empty).
>>   Later in backend bind, the password has been stripped from its OTP
>>   part and being now emptied the backend considere the connection to
>>   be anonymous authorized. Should DS also enforce the toggle at
>>   backend level ?
>>
>>   In that sense that means that the fix (test of password len to
>>   reject the bind) could/should rather be done in DS backend than in
>>   the preop plugin.
> IPA preop plugin has to check for the empty password because we update
> token-related information and user's Kerberos attributes even in case
> password failed as we need to keep track of the used token values and 
> authentication failures.
>
> Thus, I think, the check in the preop plugin is still needed.
ok I understand.
Checking/update is fine.. but I was wondering if the failure was needed 
(systematically).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141106/ee1ac673/attachment.htm>


More information about the Freeipa-devel mailing list