-----BEGIN PGP SIGNED MESSAGE-----
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


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

The Release Notes [1] 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
there.

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 [2], 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.

References
==========

URL for this Security Advisory
https://shibboleth.net/community/advisories/secadv_20170315.txt


Credits
=======
The University of Chicago
Unicon, Inc.

[1] https://wiki.shibboleth.net/confluence/display/IDP30/ReleaseNotes
[2] https://wiki.shibboleth.net/confluence/x/tABSAQ

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYyUjpAAoJEDeLhFQCJ3liRmcQAMKRRSwHeop7oMg+M7+Lj6l2
a3VHPcOZMQ8rkKkEp1QG2fdgtWUuzvE+/HoLokL+GqH48vv3Zsf50PRnlyCcUufI
cUQ+kYyWBwGCvl07gUWDHAYo2nccRUU7dNIQh/vz6vUuSSOyafWcOX9W4XE+hrbV
DbzwwHHGOTWIZ1cYxaciUD8zazJJJ+2sReRznWnlaOcTYEHtDGdiH4Dqp8lRkwep
weMv3mvSkL0jjCTLvkl6R+aedKqJ5if38tzPYXL68/kNJ6nz/AguAecffwmG39pk
oBrSfTBP9CT/p2bSg/GxDBVvsg+q1raj/S9oXCRvjVnQWp0fHdwiSbmzKtzluVKD
FldnAvUAkp94RmVErwFwcNMElY2z3qgzpnkAYDSyMfchOMiNCEOV8uHU3o9l1jOA
JCOoTfB2qWMX2lD6R3qh4DjYo6MTcbHnfHylYZqt1vTYBDiNtHp0C2kv4Sl+LpdQ
+XCm/vabFkW5u8SY/y7J6eMIrHU5+mB5lj5/Tv4hc6JQ2YcOCU5+zZyxse5vh9Qb
h0//2UoV3jZdpMjVDucjyAqOazP4GC2kaHuTSGTE+22uiw4K8ohZlh2g+ONcKANT
OaxD5cLQuktNawQAua+Dqt/cYS4z8oDoalTYZiZObnxAbOkpH3LxiPJNdezK5paN
O4YEYK6kYMCWloaxz0gN
=O1Uh
-----END PGP SIGNATURE-----