Shibboleth Identity Provider Security Advisory [15-March-2017]

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Shibboleth Identity Provider Security Advisory [15-March-2017]

Cantor, Scott E.
Hash: SHA512

Shibboleth Identity Provider Security Advisory [15 March 2017]

Design flaw can result in second-factor authentication bypass
A flaw in the authentication support in the Identity Provider software creates
opportunities for an attacker to manipulate a browser client to bypass steps
in the authentication sequence.

While there are no known exploits for the login features delivered with the
software (including the Duo Security support included with V3.3.0), the
possibility has not been ruled out. But, in practice the flaw primarily
affects third-party implementations of second-factor authentication services.

This flaw is only possible to exploit in scenarios in which the requested or
configured authentication requirements of a particular service are supplemented
by rules involving other aspects of a transaction, such as the identity of the
user. For example, requiring use of a second factor for specific users, while
allowing password authentication for other users, may be circumventable because
of this issue.

In contrast, when services request specific forms of authentication, or if the
IdP is configured to require specific forms of authentication, that requirement
is always enforced and the flaw cannot cause a result that does not satisfy
those requirements to be accepted.

Affected Versions
Versions of the Identity Provider < 3.3.1

All deployers should upgrade to V3.3.1 at the earliest opportunity.

The Release Notes [2] document describes an additional step that applies to a
very small number of deployers. The vast majority are not using this feature,
but anyone who has defined custom flow "events" in login, interceptor, or subject
canonicalization flows will need to do a bit of additional work, as described

Any deployers relying on business rules of the sort described above in which
service requirements alone do not dictate the expected policy decision on how
authentication must be performed should consider deploying an "interceptor"
flow, possibly via the delivered "context-check" feature [3], to perform a final
check that the authenticated Subject meets the requirements of the intended
policy. An example of this has been added to the documentation. This greatly
reduces the possibility that future flaws in the software might lead to
unintended results. It is also a useful means of mitigating this issue in the
event that an upgrade to the fixed version cannot be performed promptly.


URL for this Security Advisory

The University of Chicago
Unicon, Inc.




To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view

Re: Shibboleth Identity Provider Security Advisory [15-March-2017]

Cantor, Scott E.
Quick correction, the advisory on the website has had the misnumbered footnotes corrected.

-- Scott

To unsubscribe from this list send an email to [hidden email]