Hello, On Thu, 21 Jan 2021 at 11:17, Leif Johansson <leifj at sunet.se> wrote: This sounds like a better strategy. Below, I am answering the email and questions to kickstart this process. I am skeptical if we should answer the last question. Hello Lawrence, we are happy to answer these questions. Vulnerabilities, and security in general, is a sensitive topic and we would like to make sure all the details are right. Therefore, we would like to see the writeup before it goes public. Is this possible? There is no known exploitation based on those vulnerabilities. The issues were reported directly to the IdentityPython incident-response mailing list by researchers and users of the library. The incidents did not become known because of an exploitation, but because the reporters studied and analysed the code. By default, PySAML2 uses xmlsec1 as a backend to sign and verify signed XML documents and specifically, signatures on SAML Response elements and Assertion elements. The original legitimate signature cannot be the first element, because this is against the schema of SAML Response or Assertion. However, the way xmlsec1 works, is that given a scope it will validate the first signature within that scope. This allows an attacker to manipulate the document and inject a node with a valid signature before the Signature element of the Response or Assertion elements. This invalidates the structural consistency of the document. The way to prevent this issue is to ensure that the document is structurally valid, by validating it against the proper schema. If that property holds, the first signature within the given scope will always be the Signature element that will be verified by xmlsec1. The XML Digital Signature specification defines multiple types of signatures and mechanisms to sign a given document. xmlsec1 is a generic tool that implements all of those types and mechanisms. The SAML core specification, however, defines constrains on how documents are signed and verified. xmlsec1 needs to be configured to match those constrains. This is now in place; previously, an attacker could substitute the default mechanism used to sign the document and trick the verification process. An entity that receives a signed document and verifies its signature allows the data on the document to be trusted by that entity. In itself, this is not enough to exploit a system, but it does open a door for attackers to brute force their way in. An attacker would have to know or guess the right attributes of a subject in order to gain access to the system. To gain privileged access to a system, the attacker would have to know even more, in particular how the system's authorization mechanism works and trick that to gain elevated access rights - which mechanisms are triggered, what values need to be in place, and align all those for a successful bypass. Even though this might not be considered critical, we do urge everyone to update immediately. [To the board] I am not sure we should answer this. This sounds like pointing fingers. We know some users of the library, and some are visible on GitHub (see, https://github.com/IdentityPython/pysaml2/network/dependents) I think answering this, puts pressure on those projects. Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3