Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2013.0555
Two vulnerabilities identified in Shibboleth Identity Provider
18 April 2013
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: Shibboleth Identity Provider
Publisher: Shibboleth
Operating System: Windows
UNIX variants (UNIX, Linux, OSX)
Impact/Access: Reduced Security -- Remote/Unauthenticated
Resolution: Patch/Upgrade
Original Bulletin:
http://shibboleth.net/community/advisories/secadv_20130417.txt
http://shibboleth.net/community/advisories/secadv_20130417a.txt
Comment: This bulletin contains two (2) Shibboleth security advisories.
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Shibboleth Security Advisory [ 17 April 2013 ]
Identity Provider HTTPS Connections In Metadata Providers May Exhibit
Unexpected Behavior When Used With The 'disregardSslCertificate' Option
=======================================================================
The HTTPMetadataProvider and FileBackedHTTPMetadataProvider implementations
in the IdP support a configuration option 'disregardSslCertificate' to
disable TLS certificate trust evaluation when the provider is configured
with a URL containing an HTTPS scheme. It was discovered that, due to
limitations of the Jakara Commons HttpClient 3.x API, this option has a
global effect on all metadata providers configured with URLs having an HTTPS
scheme.
This will result in unintended behavior of the provider with respect to
TLS certificate trust evaluation if there are multiple metadata providers
defined in relying-party.xml with HTTPS schemes and mixed usage of the
'disregardSslCertificate' option amongst them (meaning some providers
have an effective value of 'disregardSslCertificate=true' and some have
an effective value of 'disregardSslCertificate=false').
The exact undesired behavior will vary with IdP version. For versions up
to and including 2.3.8, all HTTPS providers will have certificate trust
evaluation disabled if there is at least one provider with
'disregardSslCertificate=true'. For versions 2.4.0 and greater, the effective
setting of 'disregardSslCertificate' on the HTTPS provider defined last
in document order within relying-party.xml will determine the setting
in effect for all HTTPS providers.
Affected Versions
=================
All versions of the Identity Provider 2.x
Note that if the remote metadata being retrieved with the provider is
signed using an XML signature by the metadata publisher or source, and
the provider is properly configured to validate this metadata signature,
then this issue has greatly reduced practical significance. In this case,
the use of HTTPS is unnecessary for authentication of the metadata source,
and any issues such as this concerning transport layer security, such as
certificate trust evaluation and hostname verification, are largely irrelevant.
Recommendations
===============
The best remediation is to publish and consume only signed metadata along
with appropriately-configured signature validation within the metadata provider.
Otherwise, all HTTP-based metadata providers which use an HTTPS scheme should be
configured with the same effective setting for 'disregardSslCertificate'.
The consequence is that all HTTPS providers must and will use the same TLS
certificate trust processing behavior as determined by the value of this option.
The Shibboleth developer team recognizes that this requirement is not ideal.
The issue will be fixed in IdP 3.x with a change to use Apache HttpClient 4.x,
whose API does not suffer from the limitations of the (now end-of-life) Jakarta
Commons HttpClient 3.x.
Credits
=======
Brent Putman, Georgetown University
URL for this Security Advisory
http://shibboleth.net/community/advisories/secadv_20130417.txt
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
iEYEAREKAAYFAlFu5iIACgkQTTdwW2HLCz9rPQCfbwBk45CCjQ1G9X6KrHZMUkKX
pEkAn0HmngXx5BL6hs6RjlP4x8hFpbuJ
=nGiK
- -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Shibboleth Security Advisory [ 17 April 2013 ]
Identity Provider HTTPS Connections With HTTP-based Metadata Providers
Do Not Perform Hostname Verification
=======================================================================
The HTTPMetadataProvider and FileBackedHTTPMetadataProvider implementations
in the IdP make use of the Jakarta Commons HttpClient version 3.x. When
used with an HTTPS scheme, HttpClient by default does not perform
verification of the server hostname against the server's X.509 certificate.
The lack of hostname verification means that while the connection between
the IdP and HTTPS server is encrypted, the IdP has no way to verify
it's actually communicating with the appropriate HTTPS server hosting
the metadata.
Affected Versions
=================
Versions of the Identity Provider < 2.4.0
Note that if the remote metadata being retrieved with the provider is
signed using an XML signature by the metadata publisher or source, and
the provider is properly configured to validate this metadata signature,
then this issue has greatly reduced practical significance. In this case,
the use of HTTPS is unnecessary for authentication of the metadata source,
and any issues such as this concerning transport layer security, such as
certificate trust evaluation and hostname verification, are largely irrelevant.
Recommendations
===============
Upgrade to IdP 2.4.0 or greater, which configures an appropriate hostname
verifier for use with HttpClient, or publish and consume only signed
metadata along with appropriately-configured signature validation within
the metadata provider.
Note that in v2.4.0 and above, use of the provider configuration
option 'disregardSslCertificate' will disable hostname
verification as well as TLS certificate trust evaluation.
Credits
=======
Takeshi Nishimura, National Institute of Informatics, Japan
URL for this Security Advisory
http://shibboleth.net/community/advisories/secadv_20130417a.txt
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
iEYEAREKAAYFAlFu5h8ACgkQTTdwW2HLCz8bNgCeMM5kH4BpCrr9y4zA8n1Akhbu
wv0AnA0ICKUJTQZpxeKjlrYZZTB5chGd
=ZlL2
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/render.html?cid=1980
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBUW9xke4yVqjM2NGpAQL/GhAApMb3gw1IITI7tBq6Z1HAsSxu1yspI7Je
kea4CpqYFeZ4thCMAzPLjr4ELaUOb02tcSJF7vyJXodzZbTwZxFrwPOZQudFUQNg
ru8Pt4aGlmeFvQeBSA/otNAQzlUoD65j7gH0cQezbdkvL0qVKzp7UaqecOFWDUNy
AZ8SzwnGz9ZFD16Hd0vY4H5rK5A6fCU8fvQBpCrVvsMTfncGK9SobnmZT3ruF89a
8lXz7RfpPihxclGP9UpZKnoJlRT59ndB+Hu43WF5QDu0F2SXqvRmQvSrCko9A+FT
2q0T+ry3+NxGA1iCN1fSn7bLELJYlJY4cP++T/big3v+gR9xvMMDn4Jvbb7y6/EC
UcK4KgmHtCYFDy+jZFNkueeW8sCYDHnK3+NNtn+hVjPiVrsgo8Faw7thkxmDmOD5
DkWAeZ/VXGEtLzM6amyrX1BRcmuwUoj0VTCzwexfYkDFfOYzlrwk7v38xEVx538P
srqMPEeCOTaTyKMqQNiK9SlPG8rPC8NCxYHdDa9UX82J6ybrx5q+r+dV8Mg08J26
VW/rdxQFuOYicL7B/+Ja+tvQfhzXjjKKxi2tJ1WHq1VVjAe2oTIeYwoZRE7Ady8Q
JasJNqODUJqEXrenGbNoi1l+5SLbNoFnxWVuMQxWluz0QM6EfJUuAVT6JhFXdCOs
hJwjrd6iPp8=
=5kPZ
-----END PGP SIGNATURE-----