On 1/19/20 9:05 PM, Salvatore Bonaccorso wrote:
> Source: python-pysaml2
> Version: 4.5.0-5
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> Control: found -1 4.5.0-4
>
> Hi,
>
> The following vulnerability was published for python-pysaml2.
>
> CVE-2020-5390[0]:
> | PySAML2 before 5.0.0 does not check that the signature in a SAML
> | document is enveloped and thus signature wrapping is effective, i.e.,
> | it is affected by XML Signature Wrapping (XSW). The signature
> | information and the node/object that is signed can be in different
> | places and thus the signature verification will succeed, but the wrong
> | data will be used. This specifically affects the verification of
> | assertion that have been signed.
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2020-5390
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5390
> [1]
> https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521fd2df5b1c62e25
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
>
Hi Salvatore,
Please find attached the debdiff for fixing this CVE. I've already
uploaded the fix to Sid. Please let me know if it's ok to upload to
buster-security. BTW, are source-only uploads fine for security-master?
Cheers,
Thomas Goirand (zigo)
diff -Nru python-pysaml2-4.5.0/debian/changelog
python-pysaml2-4.5.0/debian/changelog
--- python-pysaml2-4.5.0/debian/changelog 2018-09-07 11:54:53.0
+0200
+++ python-pysaml2-4.5.0/debian/changelog 2020-02-07 09:27:20.0
+0100
@@ -1,3 +1,14 @@
+python-pysaml2 (4.5.0-4+deb10u1) buster-security; urgency=medium
+
+ * CVE-2020-5390: does not check that the signature in a SAML document is
+enveloped and thus signature wrapping is effective, i.e., it is affected by
+XML Signature Wrapping (XSW). Applied upstream patch: Fix XML Signature
+Wrapping (XSW) vulnerabilities (Closes: #949322).
+ * Remove a test file that will fail past 2020-11-28 (Closes: #949227).
+ * Add fix-importing-mock-in-py2.7.patch.
+
+ -- Thomas Goirand Fri, 07 Feb 2020 09:27:20 +0100
+
python-pysaml2 (4.5.0-4) unstable; urgency=medium
* CVE-2017-1000246: Reuse of AES initialization vector in AESCipher /
diff -Nru
python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch
python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch
---
python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch
1970-01-01 01:00:00.0 +0100
+++
python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch
2020-02-07 09:27:20.0 +0100
@@ -0,0 +1,180 @@
+Author: Ivan Kanakarakis
+Date: Sat, 4 Jan 2020 00:39:47 +0200
+Subject: CVE-2020-5390: Fix XML Signature Wrapping (XSW) vulnerabilities
+ PySAML2 did not check that the signature in a SAML document is enveloped and
thus
+ XML signature wrapping (XSW) was effective.
+ .
+ The signature information and the node/object that is signed can be in
different places
+ and thus the signature verification will succeed, but the wrong data will be
used. This
+ specifically affects the verification of assertions that have been signed.
+ .
+ This was assigned CVE-2020-5390
+ .
+ Thanks to Alexey Sintsov and Yuri Goltsev from HERE Technologies to report
this.
+ .
+ + + + + + + + +
+ .
+ In more detail:
+ .
+ libxml2 follows the xmldsig-core specification. The xmldsig specification is
way too
+ general. saml-core reuses the xmldsig specification, but constrains it to use
of
+ specific facilities. The implementation of the SAML specification is
responsible to
+ enforce those constraints. libxml2/xmlsec1 are not aware of those constraints
and thus
+ process the document based on the full/general xmldsig rules.
+ .
+ What is happening is the following:
+ .
+ - xmldsig-core allows the signature-information and the data that was signed
to be in
+ different places. This works by setting the URI attribute of the Reference
element.
+ The URI attribute contains an optional identifier of the object being
signed. (see
+ "4.4.3 The Reference Element" --
https://www.w3.org/TR/xmldsig-core1/#sec-Reference)
+ This identifier is actually a pointer that can be defined in many different
ways; from
+ XPath expressions that need to be executed(!), to a full URL that should be
fetched(!)
+ in order to recalculate the signature.
+ .
+ - saml-core section "5.4 XML Signature Profile" defines constrains on the
xmldsig-core
+ facilities. It explicitly dictates that enveloped signatures are the only
signatures
+ allowed. This mean that:
+ * Assertion/RequestType/ResponseType element
