Skip to Content.
Sympa Menu

inc-ops-notifications - [InCommon NOTICE] FW: Shibboleth Service Provider Security Advisory [4 May 2016]

Subject: InCommon Operations Notifications

List archive

[InCommon NOTICE] FW: Shibboleth Service Provider Security Advisory [4 May 2016]


Chronological Thread 
  • From: Nick Roy <>
  • To: "" <>
  • Subject: [InCommon NOTICE] FW: Shibboleth Service Provider Security Advisory [4 May 2016]
  • Date: Wed, 4 May 2016 18:42:20 +0000
  • Accept-language: en-US
  • Authentication-results: incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=none action=none header.from=internet2.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:23

While InCommon does not require use of specific SAML implementations,
Shibboleth SP is easily the most widely deployed SP software in the metadata.
Thus, we are passing along this information as a service to the community.
If you deploy Shibboleth, SimpleSAMLphp, or other software, I would highly
recommend subscribing to the various advisory lists available for those
products.

Best,

Nick
--
Nick Roy
Director of Technology and Strategy, InCommon
Internet2, Denver (GMT -6:00)






On 5/4/16, 8:37 AM, "announce on behalf of Cantor, Scott"
<
on behalf of
>
wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>
>Shibboleth Service Provider Security Advisory [4 May 2016]
>
>This issue is rated as "critical", and allows an unauthenticated
>remote attacker to access protected resources, but it affects only
>a subset of deployers.
>
>Deployers that do _not_ make use of the <PathRegex> feature are _not_
>impacted.
>
>All versions of the Shibboleth SP available are vulnerable to the
>issue, and deployers should take immediate steps as outlined in this
>advisory.
>
>Shibboleth SP software <PathRegex> feature implemented incorrectly
>=======================================================================
>The Service Provider software includes a feature to specify protection
>rules and other settings based on evaluating a regular expression
>against a portion of the requested URL path. It is used by including
>a <PathRegex> element in the <RequestMap> construct, typically in the
>shibboleth2.xml configuration file, and is documented in [1].
>
>This element supports a property named ignoreCase that was meant to
>default to "true", and would allow for a regular expression to match
>in a case-insensitive manner (e.g. the path "Foo" would match "foo").
>
>Unfortunately, the property was mistakenly implemented in reverse, and
>the "true" value was implemented to cause the matching to be
>case-sensitive. Setting the value to "false" at present results in the
>intended behavior, while appearing to specify the opposite.
>
>While patching this is extremely simple, creating a situation in which
>the setting would have the opposite meaning in different versions,
>and even worse would change its meaning after a patch, was not deemed
>to be acceptable, and so an alternative plan was developed:
>
>1. Disclose the issue and advise deployers using this feature to
>change the setting to fix their configurations for the time being.
>
>2. Create a new setting in a small feature update (V2.6.0),
>likely called "caseSensitive", that would replace use of the
>original setting. At that point, the ignoreCase setting would
>be formally deprecated and a warning logged when detected.
>
>There are no known mitigations to prevent this issue apart from
>applying this workaround.
>
>Recommendations
>===============
>Check your shibboleth2.xml configuration for the <PathRegex> element.
>If used, check for the ignoreCase attribute in the element.
>
>If found, reverse the value (true to false, false to true).
>
>If not found, add ignoreCase="false" to the element.
>
>Restarting the web server will not be required to effect the change.
>
>It is advisable that you create an XML comment near this change
>to denote the purpose and the confusing value and to revisit it
>once the new setting is made available to correct the issue.
>
>Note that if following best practices, only IIS and FastCGI
>deployments would be affected by this issue. Use of Apache commands
>to supply rules is strongly advised over use of the RequestMap
>feature, and deployers following that advice are not impacted by this
>issue. Those using the RequestMap with Apache may wish to revisit that
>approach, particularly if they are impacted by this issue.
>
>Credits
>=======
>Scott Koranda, Spherical Cow Group
>
>[1] https://wiki.shibboleth.net/confluence/x/RYBC
>
>URL for this Security Advisory:
>https://shibboleth.net/secadv/secadv_20160504.txt
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJXKgefAAoJEDeLhFQCJ3lirfcQAI2LNdhGK81+db7b1nsvWMtl
>2h8UnY0LeApEw3lHKoU/+Nl5v3ruK+PY+RvTweKDyg8xnqukP2obCdsRoiOsYqtH
>7AzcHbP9cVTbOZ9ILblZpp7XNJS+rGYzgPRcWbeUiMPLYShWNEBeVbdXuWiVjmPH
>w9HaPzR2ZpXtwopq0JqLwAGv5M68pjXEzuErkvWbaTHB/CuGaBy8YZbdaCsqpox0
>GQ83yL8mTzmVzcIk2SU68J/oj8Xan6uS7rsBfmmpZhScijj9pZbNJpIu/PfpG3cG
>2/MOfPTQA18W/xPtfjUBkTVP3PeFYcf3ahVMe0weU3tDGXVzOd60cp75b9TF4z/i
>lSRsUB2lbyh9Vdrzz3O+iSh/FhDhris6HYw4F2cZArp3tRSX68amjtmy7ugDC0lE
>prKRNjakJsfwNThCqYINhwRxoDOXyOqugEgU0LUYPIG1/sroWLCmW0DVMF13uVXx
>cfcqQbq4W0qyYoQ7MAiGtn74Bc5++duu8Cp/3YNV2ywm/31wAYlfrHuHuxfc88Ik
>Fs1R+WcH8nTi4jpir2OMBdFeIUolv6r9KctlnulipAth+BFZQV/1ZNNElAaGsgAe
>FodsUr7uDu1tFxRhllM8/yc6f1PtqXAflnYAMHoAESn3rugH1HTQ4MlluetrP0+M
>2YAT7sTmTJhRQhnnMo4O
>=ZyOp
>-----END PGP SIGNATURE-----
>--
>To unsubscribe from this list send an email to
>


  • [InCommon NOTICE] FW: Shibboleth Service Provider Security Advisory [4 May 2016], Nick Roy, 05/04/2016

Archive powered by MHonArc 2.6.16.

Top of Page