Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
On 5.11.2014 21:22, Alexander Bokovoy wrote: On Wed, 05 Nov 2014, 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 ACK. We need to do release for 4.0 and 4.1 first thing tomorrow. A possible workaround is to disable 2FA for users in mean time. Pushed to: master: 79df668b5df59813ffbb6192eecfb687bccbc0eb ipa-4-1: a601daa0117c4991ae7e198cc864246c66d36f57 ipa-4-0: 013e2eae2041729d5ee6ad4dc825bc4f24234ec6 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
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@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. When ipapwd_pre_bind, stipping the OTP part, detects that the password is zero length, I wonder if it should not test that flag to determine if it should fail or succeed. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
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@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. When ipapwd_pre_bind, stipping the OTP part, detects that the password is zero length, I wonder if it should not test that flag to determine if it should fail or succeed. Since original password was non-empty it wouldn't make sense to check the value for empty password after stripping the OTP part as it is not an unauthenticated password in the first place. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
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@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.
thanks
thierry
When ipapwd_pre_bind, stipping the OTP part, detects that the
password is zero length, I wonder if it should not test that flag to
determine if it should fail or succeed.
Since original password was non-empty it wouldn't make sense to check
the value for empty password after stripping the OTP part as it is not
an unauthenticated password in the first place.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
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@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.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
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@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).
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
On Wed, 05 Nov 2014, 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 ACK. We need to do release for 4.0 and 4.1 first thing tomorrow. A possible workaround is to disable 2FA for users in mean time. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
On Wed, 5 Nov 2014 22:22:16 +0200 Alexander Bokovoy aboko...@redhat.com wrote: On Wed, 05 Nov 2014, 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 ACK. Code sounds good, but I haven't tested it. We need to do release for 4.0 and 4.1 first thing tomorrow. Yes. A possible workaround is to disable 2FA for users in mean time. We should send a warning to freeipa-users mailing list that we are preparing a release and they should consider disabling 2FA ion the meanwhile if they are using it. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation
On Wed, 05 Nov 2014, Simo Sorce wrote: On Wed, 5 Nov 2014 22:22:16 +0200 Alexander Bokovoy aboko...@redhat.com wrote: On Wed, 05 Nov 2014, 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 ACK. Code sounds good, but I haven't tested it. We need to do release for 4.0 and 4.1 first thing tomorrow. Yes. A possible workaround is to disable 2FA for users in mean time. We should send a warning to freeipa-users mailing list that we are preparing a release and they should consider disabling 2FA ion the meanwhile if they are using it. Done. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
