Improper Verification of Cryptographic Signature in PySAML2

Description

Impact

All users of pysaml2 that use the default CryptoBackendXmlSec1 backend and need to verify signed SAML documents are impacted. pysaml2 <= 6.4.1 does not ensure that a signed SAML document is correctly signed. The default CryptoBackendXmlSec1 backend is using the xmlsec1 binary to verify the signature of signed SAML documents, but by default, xmlsec1 accepts any type of key found within the given document. xmlsec1 needs to be configured explicitly to only use only x509 certificates for the verification process of the SAML document signature.

Patches

Users should upgrade to pysaml2 v6.5.0.

Workarounds

No workaround provided at this point.

References

This issue has been reported in the past at the xmlsec1 mailing list:
https://www.aleksey.com/pipermail/xmlsec/2013/009717.html

Credits

  • Brian Wolff

For more information

If you have any questions or comments about this advisory:
* Open an issue in pysaml2
* Email us at the incident-response address

Basic information

Type
reviewed
Severity
medium
Advisory on GitHub
Open advisory ↗
Repository advisory
Open repository advisory ↗
Source code
Browse source ↗
Published (advisory)
2021-01-21 14:12:18 UTC
Updated
2024-10-14 15:41:52 UTC
GitHub reviewed
2021-01-21 14:11:58 UTC
NVD published
2021-01-21

EPSS Score

Score Percentile
2.86% 86.01%

CVSS Scores

Base score Version Severity Vector
6.5 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network—not just someone sitting at the machine.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:N)
No account or special rights needed—anonymous or random user is enough.
User interaction (UI:R)
A real person has to do something—click, install, enable—otherwise it doesn’t land.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:H)
They could widely tamper with or forge data—trust in the data is badly hurt.
Availability (A:N)
Service keeps running; no real outage angle.
6.9 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network.
Attack complexity (AC:L)
Exploitation conditions are straightforward and stable.
Attack requirements (AT:N)
No additional preconditions are required beyond normal reachability.
Privileges required (PR:N)
No privileges are required.
User interaction (UI:A)
User interaction is required in an active way.
Vulnerable system confidentiality impact (VC:N)
No confidentiality impact on the vulnerable system.
Vulnerable system integrity impact (VI:H)
High integrity impact on the vulnerable system.
Vulnerable system availability impact (VA:N)
No availability impact on the vulnerable system.
Subsequent system confidentiality impact (SC:N)
No confidentiality impact on subsequent systems.
Subsequent system integrity impact (SI:N)
No integrity impact on subsequent systems.
Subsequent system availability impact (SA:N)
No availability impact on subsequent systems.

Identifiers

CWEs

CWE id Name
CWE-347 Improper Verification of Cryptographic Signature

Credits

  • bawolff (analyst)

Affected packages (1)

Vulnerable version ranges and first patched releases as published by GitHub.

Ecosystem Package Vulnerable range First patched Vulnerable functions
pip pysaml2 < 6.5.0 6.5.0

References

cvelogic Threat Intelligence