Shibboleth Service Provider Security Advisory [27 February 2018]

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

Shibboleth Service Provider Security Advisory [27 February 2018]

Cantor, Scott E.
Hash: SHA256

Shibboleth Service Provider Security Advisory [27 February 2018]

An updated version of the Shibboleth Project's XMLTooling library is
available which corrects a critical security issue.

Shibboleth SP software vulnerable to additional data forgery flaws
The XML processing performed by the Service Provider software has been
found to be vulnerable to new flaws similar in nature to the one
addressed in an advisory last month [1].

These bugs involve the use of other XML constructs rather than entity
references, and therefore required additional mitigation once discovered.
As with the previous issue, this flaw allows for changes to an XML document
that do not break a digital signature but can alter the user data passed
through to applications behind the SP and result in impersonation attacks
and exposure of protected information.

As before, the use of XML Encryption is a significant mitigation, but we
have not dismissed the possibility that attacks on the Response "envelope"
may be possible, in both the original and this new case. No actual attacks
of this nature are known, so deployers should prioritize patching systems
that expect to handle unencrypted SAML assertions.

An updated version of XMLTooling-C (V1.6.4) is available [2] that protects
against these new attacks, and should help prevent similar vulnerabilities
in the future.

Unlike the previous case, these bugs are NOT prevented by any existing
Xerces-C parser version on any platform and cannot be addressed by any
means other than the updated XMLTooling-C library.

ALL supported (and unsupported) platforms are impacted by these bugs,
including Windows, Linux, Solaris, and OS X.

This vulnerability has been assigned CVE-2018-0489 and is referenced by
a CERT Vulnerability Note at [3].

Upgrade to V1.6.4 or later of the XMLTooling-C library and restart the
affected processes (shibd, Apache, etc.)

Linux installations relying on official RPM packages can upgrade to
the latest package versions to obtain the fix.

The MacPort has also been updated.

Windows systems can upgrade to the latest Service Provider release
(V2.6.1.4) which contains the appropriately updated libraries. [4]

Kelby Ludwig, Duo Security
Scott Cantor, Shibboleth Project


URL for this Security Advisory:

Version: GnuPG v2


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

Re: Shibboleth Service Provider Security Advisory [27 February 2018]

Cantor, Scott E.
I'm taking the unusual step of adding a follow up announcement on this for a couple of reasons. Firstly, it's not solely a Shibboleth bug and there's a blog article from the Duo researcher now that people should know about. [1]

Secondly, the implications here may not be clear, so I want to reinforce this: people have not found all the implementations that are vulnerable to this bug and its siblings. CERT reached out to many, but they can't hit everybody, and they naturally omitted a whole lot of the one-off stacks out there used by cloud vendors which many in this community use Shibboleth routinely to integrate.

As part of my nature study for this process, I investigated, discreetly, a number of SPs that my university has campus-wide integrations with and that did not support XML Encryption. This is the sweet spot for the bug, because truncation attacks generally require overlapping user identifiers, and 150,000 identities provides that kind of thing.

Out of about 6 I checked, 4 were vulnerable and none of them likely know about this yet. I've started my own campus process of reporting the issues and turning the long crank of getting the vendors aware of them. Unfortunately, this is a process that many of us are going to have to spend time on.

Some of them were vulnerable to the previous bug we fixed last month, and I also am not even sure that Duo understands the full range of potential flaws here because I found successful attacks that were similar to, but not the same as, the one they formally reported. This is going to be a process.

Again, focus on the unencrypted integrations. I would also urge all of us to begin to insist on the use of XML Encryption going forward. We will also need to begin the long process of forcing implementations to get compliant with AES-GCM encryption, which will be the default in Shibboleth V4, and which replaces the long-broken AES-CBC encryption used almost universally in SAML today. It's time to fix that.

-- Scott


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