Summary
SimpleSAMLphp's HTTP-Artifact receive path can treat an unsigned embedded SAML Response as cryptographically valid for the wrong IdP.
In the HTTPArtifact::receive() flow, the SOAP ArtifactResponse receives a TLS-based validator from SOAPClient::addSSLValidator(). The embedded SAML Response then receives a validator that delegates signature validation to that outer ArtifactResponse. Later, the SP validates the embedded Response against metadata selected from the embedded response issuer, not necessarily the artifact issuer.
The critical issue is that SOAPClient::validateSSL() returns normally when the TLS public key does not match the key currently being validated. SAML2\Message::validate() treats any validator call that does not throw an exception as successful. As a result, an ArtifactResponse obtained from one IdP can validate an unsigned embedded SAML Response that claims to be issued by a different IdP.
In a multi-IdP/federation deployment where a malicious or lower-trust IdP can issue an HTTP-Artifact response to an SP, this can allow the attacker to authenticate to the SP as arbitrary users from a higher-trust victim IdP.
Impact
A malicious or lower-trust IdP in the same SP/federation trust set can authenticate to the SP as users from another IdP when HTTP-Artifact is used. The attacker can choose assertion attributes, NameID, and session data in the forged unsigned assertion.
This is an authentication bypass and identity-provider impersonation issue. In realistic federations, the security boundary between IdPs matters: a compromised or low-assurance IdP should not be able to mint identities for a high-assurance IdP.
References
kamil-sawicki Reporter
Summary
SimpleSAMLphp's HTTP-Artifact receive path can treat an unsigned embedded SAML
Responseas cryptographically valid for the wrong IdP.In the
HTTPArtifact::receive()flow, the SOAPArtifactResponsereceives a TLS-based validator fromSOAPClient::addSSLValidator(). The embedded SAMLResponsethen receives a validator that delegates signature validation to that outerArtifactResponse. Later, the SP validates the embeddedResponseagainst metadata selected from the embedded response issuer, not necessarily the artifact issuer.The critical issue is that
SOAPClient::validateSSL()returns normally when the TLS public key does not match the key currently being validated.SAML2\Message::validate()treats any validator call that does not throw an exception as successful. As a result, anArtifactResponseobtained from one IdP can validate an unsigned embedded SAMLResponsethat claims to be issued by a different IdP.In a multi-IdP/federation deployment where a malicious or lower-trust IdP can issue an HTTP-Artifact response to an SP, this can allow the attacker to authenticate to the SP as arbitrary users from a higher-trust victim IdP.
Impact
A malicious or lower-trust IdP in the same SP/federation trust set can authenticate to the SP as users from another IdP when HTTP-Artifact is used. The attacker can choose assertion attributes,
NameID, and session data in the forged unsigned assertion.This is an authentication bypass and identity-provider impersonation issue. In realistic federations, the security boundary between IdPs matters: a compromised or low-assurance IdP should not be able to mint identities for a high-assurance IdP.
References