Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Details The validateSignature function in validate.go goes through the references in the SignedInfo block to find one that matches the signed element's ID. In Go versions before 1.22, or when go.mod uses an older version, there is a loop variable capture issue. The code takes the address of the loop variable ref instead of its value. As a result, if more than one reference matches the ID or if the loop logic is incorrect, the ref pointer will always end up pointing to the last element in the SignedInfo.References slice after the loop. ------ Technical Details The code takes the address of a loop iteration variable (&ref). In the standard Go compiler, this variable is only allocated once for the whole loop, so its address stays the same, but its value changes with each iteration. As a result, any pointer to this variable will always point to the value of the last element processed by the loop, no matter which element matched the search criteria. Using Radare2, I found that the…
Recommended action: Upgrade to 1.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In versions prior to v0.7.0 it was possible for an attacker to supply an invalid assertion which would trigger a panic due to a nil-pointer dereference. Patches The issue was patched in v0.7.0, released on March 2, 2022. Workarounds Callers to gosaml2 can use recover() to handle panics to mitigate a potential DoS. References See issue #59 for details.
Recommended action: Upgrade to 1.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This affects all versions of package github.com/russellhaering/goxmldsig prior to 1.1.1. There is a crash on nil-pointer dereference caused by sending malformed XML signatures. This issue is patched in version 1.1.1.
Recommended action: Upgrade to 1.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The following vulnerabilities have been disclosed, which impact users leveraging the SAML connector: Signature Validation Bypass (CVE-2020-15216): https://github.com/russellhaering/goxmldsig/security/advisories/GHSA-q547-gmf8-8jr7 encoding/xml instabilities: - Element namespace prefix instability (CVE-2020-29511) - Attribute namespace prefix instability (CVE-2020-29509) - Directive comment instability (CVE-2020-29510) Patches Immediately update to Dex v2.27.0. Workarounds There are no known workarounds.
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authentication bypass exists in the goxmldsig this library uses to determine if SAML assertions are genuine. An attacker could craft a SAML response that would appear to be valid but would not have been genuinely issued by the IDP. Patches Version 0.4.2 bumps the dependency which should fix the issue. For more information Please see the advisory in goxmldsig Credits The original vulnerability was discovered by @jupenur. Thanks to @russellhaering for the heads up.
Recommended action: Upgrade to 0.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact With a carefully crafted XML file, an attacker can completely bypass signature validation and pass off an altered file as a signed one. Patches A patch is available, all users of goxmldsig should upgrade to v1.1.0. For more information If you have any questions or comments about this advisory open an issue at https://github.com/russellhaering/goxmldsig
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.