Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2014.0480
Shibboleth Security Advisory [9 April 2014]
10 April 2014
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: Shibboleth Service Provider
Publisher: Shibboleth
Operating System: UNIX variants (UNIX, Linux, OSX)
Windows
Impact/Access: Access Privileged Data -- Remote/Unauthenticated
Resolution: Patch/Upgrade
CVE Names: CVE-2014-0160
Reference: ESB-2014.0457
Original Bulletin:
http://shibboleth.net/community/advisories/secadv_20140409.txt
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Shibboleth Security Advisory [9 April 2014]
An updated version of the OpenSSL library, 1.0.1g, is available
that corrects a serious bug that can lead to information leakage,
including disclosure of private keys.
Refer to the Recommendations section below for specific guidance on
how particular platforms are affected.
OpenSSL "Heartbleed" vulnerability
====================================================================
A security advisory for versions of OpenSSL 1.0.1 prior to 1.0.1g
has been issued for a serious vulnerability known as "Heartbleed".
The vulnerability has been published as CVE-2014-0160 and a website
describing the issue can be found at http://heartbleed.com
Since Shibboleth products make extensive use of TLS, and the Service
Provider itself uses OpenSSL directly, deployments of both Identity
and Service Providers *may* be affected by this issue.
Since both products are generally deployed in a web environment,
it may be necessary to revoke existing browser-facing TLS certificates
and obtain new ones, if the web server itself relied on an
affected version of OpenSSL.
The IdP product is a Java implementation, and as such does not
directly make use of OpenSSL, but is often deployed in conjunction
with Apache as a web server. In addition, it is common to support
certain SAML profiles involving SOAP by deploying a common key for
both signature generation and TLS security on a non-browser-facing
port, such as 8443. In such a case, a vulnerable OpenSSL version
could have disclosed that key.
The SP product makes direct use of OpenSSL, and due to the nature
of this bug, it is possible for an SP's local signing/authentication
key to be disclosed in the course of connecting to a malicious
system in the course of performing SOAP-based requests or metadata
retrieval.
In the specific case of a Shibboleth SP on Windows, versions 2.5.0
and later included a vulnerable version of OpenSSL. Earlier versions
did not. On other platforms, the version of OpenSSL will depend on
the OS, or local installation choices, and so may or may not be
affected on a case by case basis, much like the IdP.
All deployers should assess their systems in light of this issue,
and may need to take additional remedial steps beyond simply patching
their systems if the possibility exists for private key exposure.
In the specific case of Microsoft Windows, a patch is available for
the Service Provider 2.5.3 release that updates the version of OpenSSL
to the patched version, 1.0.1g.
Many federations in higher education that make use of Shibboleth
or other SAML products have, or are likely to, issue advisories
regarding this issue, and they may provide more concrete guidance
to their communities.
Recommendations
===============
First and foremost, ensure that patches are applied to any OpenSSL
libraries in use that are vulnerable to this issue.
For Windows installations, a patch [1][2] is now available to update
version 2.5.3 to the latest OpenSSL revision to correct the issue.
Older Windows versions containing affected versions need to be
updated to 2.5.3 to apply this patch.
The installer for 2.5.3 has been updated to include this patch.
Systems that had been vulnerable to this issue need to carefully
consider the implications, and taking a conservative view, it is
wise to move forward with a key migration to replace any SAML
signing or encryption keys that may have been compromised. Most,
though not all, systems relying on Shibboleth also rely on a trust
model based on SAML metadata that allows keys to be "revoked" by
simply removing them from metadata after having migrated to a new
key.
The Shibboleth documentation and federations such as InCommon have
provided material about key migration that may be of use [3][4].
URL for this Security Advisory:
http://shibboleth.net/community/advisories/secadv_20140409.txt
[1] http://shibboleth.net/downloads/service-provider/2.5.3/win32/
[2] http://shibboleth.net/downloads/service-provider/2.5.3/win64/
[3] https://wiki.shibboleth.net/confluence/x/KIFC
[4] https://spaces.internet2.edu/x/vAEFAQ
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJTRWn0AAoJEDeLhFQCJ3li2iQP/ii0IsqXlGTI1LQNsmYSa701
PLbTIkTaCiK7sqH10gAHvbFNfSBOZ0RTjAvcnDVpfb3qSYkqe4ZqjRGEk/UlU00w
L4fKPi6hsz0p0Ud/D9TYX6X/yd+J4hQwvtv/aK1UyMlKSIUG7PPsnmFrKy8ZFcKp
AeYumK8ZPJAitiueZ3mQO396Y2Cp3aP9lWAR+1qlSyKqeAHbLpCZ03vUodaCo16k
GZtoxd24zDSOiE9su1tphlnJrTRigqMcDSp3fCZFDzts8pdaejaEq4IC5rHSJsvE
Uv2XWM9Ks7vKQKoZ2Fs6+x8qe943bgYGc2C/Lzy9F12gZwwbt8XD0U8T87S9kZDT
vbVV3i5RFTaQ2xH7PI/NUW8bAGKHUwb+nzRTcL8r1/LAoYOiGZvB04oBgsZQdxFr
EcESI479KTibPMO4ZchZdDM6hAUpPbSZMcWB6hhp1mcSoE8guiYRIhOytC817CEb
KxvqfLIme6kGtkSsowEzuB8EMUjJQvqQeskDZ9qwfIkqaOIGUH7/1ExWeGRH7eUd
JpVLEivZhxN+Ph+DeTMP6BE+nGhY9lv1/UXOzPfNtO+zOmzYqUAuV/Al6IS0xDZ/
hSsp+Vvol2/h4cMYg9doRvm1ugGPeW3C8AfZ8EgLC+C8gyJNa1QDPj8dZjx0GcPc
IKYti72o5kKp6oF53wnO
=7ZQR
- -----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
iQIVAwUBU0Xs3BLndAQH1ShLAQImww/+OoQMbmOs3Tb+1feClCDzWKkVAojFcazS
XqJ0ApTSRLqwCdaGF+x/o5/4aa2YmzaQZmIlXUM6BeBc8llMQV8j9baH5jUrPwuu
pCVwfRZ8mYb/xnuIqO7CL02GMGHXGKX3D1H3VPREatcc74WGxIk/viIt/s/iwdtz
BYR9Tzg95kdqAyyNUrVGsYqm6o96oLaNg7mLo1SN+Is7lIPdh5P2dyk/0IrOljfB
AV4Y2Kp6d1TVYmQrquRRCaP7qFVEOwkNXfNkdOVjr0z5OXK3iaI57qlwTxmzvWjH
th9QZjCBFVSMIp1B8xyiRKN+ZDz5lXW3086XQBnqQdNjKWVc39/0/FZR3LsH6Uoa
LwpQ8Lx2hm7AzDUiOUlD+8OARnt5zApcruNG20AKxSEZfqKOXYB697ishduOfryQ
c/nRi6wASjIR63iQ366u1EcQ28SaT6jAbTHHKndzBzEDC+rZltgURkCAKco2gyUK
4Ex+Qz1OVv4cdvQ63pEGx3kok4o80vjaIxtsDLjWGWGUbiH4kuQuRohYk5Q4g9XY
whkhJBKZ+VkNlulSt+jAP8Mq214bu3gx7U1FGeyCAmwO58UqzwdHSckDHAuMYt1l
aHsXocYT6UTDbQecIC+vnevrGbVTZlGfNl47er8+HtY2oIh/DQJckVDY2bjosqkb
Xw/3XqC7Vj0=
=+oLe
-----END PGP SIGNATURE-----