SimpleSAMLphp 1.15.4

[Jaime Perez Crespo]

Hi,

SimpleSAMLphp 1.15.4 has been released. This is a security release related to the following issue:

https://simplesamlphp.org/security/201803-01

This issue as been rated with medium risk, affecting mostly SimpleSAMLphp service providers. Although the consequences of the issue are serious, we consider it to be difficult to exploit, involving in most case human intervention by the SP operators. In any case, and as usual, we recommend upgrading as soon as possible.

Please refer to the changelog for more information. The changelog and upgrade notes are available here, respectively:

https://simplesamlphp.org/docs/stable/simplesamlphp-changelog
https://simplesamlphp.org/docs/stable/simplesamlphp-upgrade-notes-1.15

The new release is available for download here:

https://github.com/simplesamlphp/simplesamlphp/releases/download/v1.15.4/simplesamlphp-1.15.4.tar.gz

You can verify the integrity of this file by comparing the SHA256 digest: 349cf5d9f9ecbbced0e6f6794d26d5242fc9dafbd34268aeeb200182c24f88a5

Regards,

—
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Jaime Perez Crespo]

Hi,

CVE ID 2018-7711 has been assigned to SSPSA 201803-01:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7711

[Stefan Winter]

Hello,

a question about the "Impact" section of this advisory.

The section states:

"SimpleSAMLphp supports only RSA signatures and keys."

I am using SSP 1.15 just fine with ECDSA keys (on the IdP, to sign
assertions, and on SPs, to validate the assertions). So, I wonder if
that is really true.

Did you maybe mean to write "SimpleSAMLphp does not support DSA
signatures and keys."

If that's the case, the enumeration of cases for exploitability of the
issue might need a re-think? I can imagine the cases:

Using a ECDSA public key to validate an XML signature made with an
RSA-related algorithm.
Using an RSA public key to validate an XML signature made with a
ECDSA-related algorithm.

Considering that my ECDSA key is now in production use (eduGAIN), many
SPs have this type of key in their saml20-idp-remote metadata now.

Does this mean an attacker can craft assertions seeming to come from my
IdP, sign them with an RSA key, and will pass validation at SPs which
only have the ECDSA key configured - or vice versa?

Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

[Jaime Perez Crespo]

Hi Stefan,

On 9 May 2018, at 08:15 AM, Stefan Winter <stefan...@restena.lu> wrote:
> Hello,
>
> a question about the "Impact" section of this advisory.
>
> The section states:
>
> "SimpleSAMLphp supports only RSA signatures and keys."
>
> I am using SSP 1.15 just fine with ECDSA keys (on the IdP, to sign
> assertions, and on SPs, to validate the assertions). So, I wonder if
> that is really true.

SSP supports whatever xmlseclibs supports. That given, xmlseclibs has never claimed support for ECDSA keys, hence SSP didn’t claim it either.

I believe the issue here is related to the transport used for RSA keys, which happens to be the same for ECDSA keys. In any case, I’m really surprised to hear that it just works™. Could you share the entityID of your SAML entity with ECDSA keys so that I could do some tests myself?

> Did you maybe mean to write "SimpleSAMLphp does not support DSA

> signatures and keys.”

That might be a better description in this case, although I still believe ECDSA signatures shouldn’t work.

> If that's the case, the enumeration of cases for exploitability of the
> issue might need a re-think? I can imagine the cases:
>
> Using a ECDSA public key to validate an XML signature made with an
> RSA-related algorithm.
> Using an RSA public key to validate an XML signature made with a
> ECDSA-related algorithm.
>
> Considering that my ECDSA key is now in production use (eduGAIN), many
> SPs have this type of key in their saml20-idp-remote metadata now.
>
> Does this mean an attacker can craft assertions seeming to come from my
> IdP, sign them with an RSA key, and will pass validation at SPs which
> only have the ECDSA key configured - or vice versa?

No. Or at least, no if they are running the last version of SimpleSAMLphp. If they are running and older version, that might be the case.

—
Jaime Pérez
Uninett / Feide

[Stefan Winter]

Hello,

I was as surprised as you are now :-) I was looking at xmlseclibs code,
and convinced myself that ECDSA cannot possibly work - but then it did.

The entity ID is:

https://clueless.restena.lu/simplesamlphp/saml2/idp/metadata.php

It curently has new_* rollover in metadata, so you'll see an RSA and
ECDSA key.

For verification, I had actually switched the installation to using
ECDSA only, and it did what it should - SSP on the SP side validated the
SAML assertion when the correct cert was in place, and it didn't
validate when a different ECDSA cert was signing the assertion.

At some point I reverted to use the RSA key by default, because pretty
much every other SAML implementation except SSP threw errors generously
when seeing a ECDSA cert.

I'm happy to run tests with you off-list.

Stefan

[Jaime Perez Crespo]

Hi Stefan!

On 14 May 2018, at 09:35 AM, Stefan Winter <stefan...@restena.lu> wrote:
> Hello,
>

> I was as surprised as you are now :-) I was looking at xmlseclibs code,
> and convinced myself that ECDSA cannot possibly work - but then it did.
>
> The entity ID is:
>
> https://clueless.restena.lu/simplesamlphp/saml2/idp/metadata.php
>
> It curently has new_* rollover in metadata, so you'll see an RSA and
> ECDSA key.
>
> For verification, I had actually switched the installation to using
> ECDSA only, and it did what it should - SSP on the SP side validated the
> SAML assertion when the correct cert was in place, and it didn't
> validate when a different ECDSA cert was signing the assertion.
>
> At some point I reverted to use the RSA key by default, because pretty
> much every other SAML implementation except SSP threw errors generously
> when seeing a ECDSA cert.
>
> I'm happy to run tests with you off-list.

Thanks for your offer! I’m a bit worried about this uncovering some possible signature-bypass issue, so it would be nice if we can test it properly. The fact that the SSP service provider didn’t validate the signature when you changed the ECDSA signing cert makes me calm down a bit, but I’m still nervous about it. Did you change the cert sent in the SAML response, or did you change the key used to sign? Have you tried using a different ECDSA key to sign, but sending the same cert (as the one kept by the SP in the remote IdP metadata) in the signed response?

What I’m thinking here is that the underlying OpenSSL implementation might be making it transparent for the PHP API, making it “automagically” work. However, it should really not work since the algorithm identifier for ECDSA-SHA* signatures is obviously different, and xmlseclibs should fail at that point.

I’ve been on holidays for a few days and before that I’ve been working a lot in a fork of xmlseclibs, rewriting it from the ground up and providing a cleaner, safer API. This unfortunately has the side effect that the current inner details of xmlseclibs are deeply buried inside my brain, so I need to go through the code, preferably with a debugger. Would it be possible for you to add metadata for a couple test SPs and provide me with a guest account that I could use in your IdP? That way I would be able to debug the code line by line and find out what’s going on, without bothering you at all :-)