CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1336 vulnerabilities reference this CWE, most recent first.
GHSA-CQVM-J2R2-HWPG
Vulnerability from github – Published: 2023-03-17 14:42 – Updated: 2023-03-17 14:42Summary
Diffie-Hellman key validation is insufficient, which can lead to insecure shared secrets and therefore breaks confidentiality.
Details
Russh does not validate Diffie-Hellman keys.
It accepts received DH public keys $e$ where $e<0$, $e=1$, or $e \geq p-1$ from a misbehaving peer annd successfully performs key exchange.
This is a violation of RFC 4253, section 8 and RFC 8268, section 4, which state that:
DH Public Key values MUST be checked and both conditions:
- $1 < e < p-1$
- $1 < f < p-1$
MUST be true. Values not within these bounds MUST NOT be sent or accepted by either side. If either one of these conditions is violated, then the key exchange fails.
For example, a DH client public key $e=1$ would mean that the shared secret that the server calculates is always $K = e^y \mod{p} = 1^y \mod{p} = 1$. In other cases, an insecure order-2 subgroup may be used.
Also, the code does not look like it ensures that the generated secret key $y$ is in the valid interval $0 < y < q$ (or, if russh is the client, that the secret key $x$ satisfies $1 < x < q$):
https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L72-L76
For example, rng.gen_biguint() might return a number consisting of zeroes, so that $y = 0$.
The public key is not validated either: https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L78-L81
Impact
Due to the issues in the DH key generation, I think any connection that uses Diffie-Hellman key exchange is affected. Connections between a russh client and server or those of a russh peer with some other misbehaving peer are most likely to be problematic. These may vulnerable to eavesdropping.
Most other implementations reject such keys, so this is mainly an interoperability issue in such a case.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "russh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.36.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "russh"
},
"ranges": [
{
"events": [
{
"introduced": "0.37.0"
},
{
"fixed": "0.37.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-28113"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-17T14:42:45Z",
"nvd_published_at": "2023-03-16T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nDiffie-Hellman key validation is insufficient, which can lead to insecure shared secrets and therefore breaks confidentiality.\n\n### Details\n\nRussh does not validate Diffie-Hellman keys.\n\nIt accepts received DH public keys $e$ where $e\u003c0$, $e=1$, or $e \\geq p-1$ from a misbehaving peer annd successfully performs key exchange.\n\nThis is a violation of [RFC 4253, section 8](https://www.rfc-editor.org/rfc/rfc4253#section-8) and [RFC 8268, section 4](https://www.rfc-editor.org/rfc/rfc8268#section-4), which state that:\n\n\u003eDH Public Key values MUST be checked and both conditions:\n\u003e\n\u003e - $1 \u003c e \u003c p-1$\n\u003e - $1 \u003c f \u003c p-1$\n\u003e\n\u003e MUST be true. Values not within these bounds MUST NOT be sent or\n\u003e accepted by either side. If either one of these conditions is\n\u003e violated, then the key exchange fails.\n\nFor example, a DH client public key $e=1$ would mean that the shared secret that the server calculates is always $K = e^y \\mod{p} = 1^y \\mod{p} = 1$.\nIn other cases, an insecure order-2 subgroup may be used.\n\nAlso, the code does not look like it ensures that the generated secret key $y$ is in the valid interval $0 \u003c y \u003c q$ (or, if russh is the client, that the secret key $x$ satisfies $1 \u003c x \u003c q$):\nhttps://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L72-L76\nFor example, `rng.gen_biguint()` might return a number consisting of zeroes, so that $y = 0$.\n\nThe public key is not validated either:\nhttps://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L78-L81\n\n### Impact\n\nDue to the issues in the DH key generation, I think any connection that uses Diffie-Hellman key exchange is affected.\nConnections between a russh client and server or those of a russh peer with some other misbehaving peer are most likely to be problematic. These may vulnerable to eavesdropping.\n\nMost other implementations reject such keys, so this is mainly an interoperability issue in such a case.\n",
"id": "GHSA-cqvm-j2r2-hwpg",
"modified": "2023-03-17T14:42:45Z",
"published": "2023-03-17T14:42:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/warp-tech/russh/security/advisories/GHSA-cqvm-j2r2-hwpg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28113"
},
{
"type": "WEB",
"url": "https://github.com/warp-tech/russh/commit/45d2d82930bf4a675bd57abfafec8fe4065befcd"
},
{
"type": "WEB",
"url": "https://github.com/warp-tech/russh/commit/d831a3716d3719dc76f091fcea9d94bd4ef97c6e"
},
{
"type": "PACKAGE",
"url": "https://github.com/warp-tech/russh"
},
{
"type": "WEB",
"url": "https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L72-L76"
},
{
"type": "WEB",
"url": "https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L78-L81"
},
{
"type": "WEB",
"url": "https://github.com/warp-tech/russh/releases/tag/v0.36.2"
},
{
"type": "WEB",
"url": "https://github.com/warp-tech/russh/releases/tag/v0.37.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "russh may use insecure Diffie-Hellman keys"
}
GHSA-CQVV-R3G3-26RF
Vulnerability from github – Published: 2023-10-23 03:30 – Updated: 2023-10-31 22:07pkg/suci/suci.go in free5GC udm before 1.2.0, when Go before 1.19 is used, allows an Invalid Curve Attack because it may compute a shared secret via an uncompressed public key that has not been validated. An attacker can send arbitrary SUCIs to the UDM, which tries to decrypt them via both its private key and the attacker's public key.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/udm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-46324"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-24T02:00:10Z",
"nvd_published_at": "2023-10-23T01:15:07Z",
"severity": "HIGH"
},
"details": "pkg/suci/suci.go in free5GC udm before 1.2.0, when Go before 1.19 is used, allows an Invalid Curve Attack because it may compute a shared secret via an uncompressed public key that has not been validated. An attacker can send arbitrary SUCIs to the UDM, which tries to decrypt them via both its private key and the attacker\u0027s public key.",
"id": "GHSA-cqvv-r3g3-26rf",
"modified": "2023-10-31T22:07:50Z",
"published": "2023-10-23T03:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46324"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/udm/pull/20"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/udm/commit/5e1479cc686f058992557669b13fd3761a1b6024"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/udm"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/udm/compare/v1.1.1...v1.2.0"
},
{
"type": "WEB",
"url": "https://www.gsma.com/security/wp-content/uploads/2023/10/0073-invalid_curve.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "free5GC udm vulnerable to Invalid Curve Attack"
}
GHSA-CRH8-242H-76G6
Vulnerability from github – Published: 2026-08-21 00:31 – Updated: 2026-08-21 00:31Improper verification of cryptographic signature in Azure Data Factory allows an unauthorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-62834"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-20T22:17:43Z",
"severity": "CRITICAL"
},
"details": "Improper verification of cryptographic signature in Azure Data Factory allows an unauthorized attacker to elevate privileges over a network.",
"id": "GHSA-crh8-242h-76g6",
"modified": "2026-08-21T00:31:21Z",
"published": "2026-08-21T00:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62834"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62834"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CRQ4-6FJX-J758
Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2022-02-17 00:00There is a vulnerability of signature verification mechanism failure in system upgrade through recovery mode.Successful exploitation of this vulnerability may affect service confidentiality.
{
"affected": [],
"aliases": [
"CVE-2021-40045"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-09T23:15:00Z",
"severity": "MODERATE"
},
"details": "There is a vulnerability of signature verification mechanism failure in system upgrade through recovery mode.Successful exploitation of this vulnerability may affect service confidentiality.",
"id": "GHSA-crq4-6fjx-j758",
"modified": "2022-02-17T00:00:47Z",
"published": "2022-02-11T00:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40045"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2022/2"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202202-0000001204253396"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CVCQ-MW35-Q882
Vulnerability from github – Published: 2022-11-04 19:01 – Updated: 2022-11-08 19:00A CWE-347: Improper Verification of Cryptographic Signature vulnerability exists in the SGIUtility component that allows adversaries with local user privileges to load a malicious DLL which could result in execution of malicious code. Affected Products: EcoStruxure Operator Terminal Expert(V3.3 Hotfix 1 or prior), Pro-face BLUE(V3.3 Hotfix1 or prior).
{
"affected": [],
"aliases": [
"CVE-2022-41669"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-04T13:15:00Z",
"severity": "HIGH"
},
"details": "A CWE-347: Improper Verification of Cryptographic Signature vulnerability exists in the SGIUtility component that allows adversaries with local user privileges to load a malicious DLL which could result in execution of malicious code. Affected Products: EcoStruxure Operator Terminal Expert(V3.3 Hotfix 1 or prior), Pro-face BLUE(V3.3 Hotfix1 or prior).",
"id": "GHSA-cvcq-mw35-q882",
"modified": "2022-11-08T19:00:22Z",
"published": "2022-11-04T19:01:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41669"
},
{
"type": "WEB",
"url": "https://www.se.com/ww/en/download/document/SEVD-2022-284-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CVP8-5R8G-FHVQ
Vulnerability from github – Published: 2024-09-11 21:08 – Updated: 2024-09-19 18:25ruby-saml, the dependent SAML gem of omniauth-saml has a signature wrapping vulnerability in <= v1.12.0 and v1.13.0 to v1.16.0 , see https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2 As a result, omniauth-saml created a new release by upgrading ruby-saml to the patched versions v1.17.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "omniauth-saml"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "omniauth-saml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "omniauth-saml"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-11T21:08:26Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "ruby-saml, the dependent SAML gem of omniauth-saml has a signature wrapping vulnerability in \u003c= v1.12.0 and v1.13.0 to v1.16.0 , see https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2 \nAs a result, omniauth-saml created a [new release](https://github.com/omniauth/omniauth-saml/releases) by upgrading ruby-saml to the patched versions v1.17. \n",
"id": "GHSA-cvp8-5r8g-fhvq",
"modified": "2024-09-19T18:25:42Z",
"published": "2024-09-11T21:08:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2"
},
{
"type": "WEB",
"url": "https://github.com/omniauth/omniauth-saml/security/advisories/GHSA-cvp8-5r8g-fhvq"
},
{
"type": "WEB",
"url": "https://github.com/omniauth/omniauth-saml/commit/4274e9d57e65f2dcaae4aa3b2accf831494f2ddd"
},
{
"type": "WEB",
"url": "https://github.com/omniauth/omniauth-saml/commit/6c681fd082ab3daf271821897a40ab3417382e29"
},
{
"type": "PACKAGE",
"url": "https://github.com/omniauth/omniauth-saml"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/omniauth-saml/GHSA-cvp8-5r8g-fhvq.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "omniauth-saml vulnerable to Improper Verification of Cryptographic Signature"
}
GHSA-CWPH-2586-4QWC
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-10 15:33Improper verification of cryptographic signature and Improper Check for Unusual or Exceptional Conditions vulnerability in Estonian Information System Authority (RIA) libdigidocpp, DigiDoc4, DigiDoc on Android, and DigiDoc on iOS. This issue affects libdigidocpp: from 4.1.0 before 4.2.1; DigiDoc4: from 4.7.0 before 4.8.2; DigiDoc on Android: from 2.7.0 before 2.7.2; DigiDoc on iOS: from 2.8.0 before 2.8.1.
{
"affected": [],
"aliases": [
"CVE-2026-59112"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T14:17:25Z",
"severity": "MODERATE"
},
"details": "Improper verification of cryptographic signature and Improper Check for Unusual or Exceptional Conditions vulnerability in Estonian Information System Authority (RIA) libdigidocpp, DigiDoc4, DigiDoc on Android, and DigiDoc on iOS.\u00a0This issue affects libdigidocpp: from 4.1.0 before 4.2.1; DigiDoc4: from 4.7.0 before 4.8.2; DigiDoc on Android: from 2.7.0 before 2.7.2; DigiDoc on iOS: from 2.8.0 before 2.8.1.",
"id": "GHSA-cwph-2586-4qwc",
"modified": "2026-08-10T15:33:51Z",
"published": "2026-08-10T15:33:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59112"
},
{
"type": "WEB",
"url": "https://github.com/open-eid/libdigidocpp/pull/690"
},
{
"type": "WEB",
"url": "https://www.id.ee/en/article/ria-soovitab-kasutajatel-uuendada-id-tarkvara-eng"
},
{
"type": "WEB",
"url": "https://www.ria.ee/blogi/digidoc-rakendustes-esinenud-turvanorkus-mis-juhtus-ja-kuidas-see-parandati"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-CX5H-J8W3-WHPR
Vulnerability from github – Published: 2025-12-12 21:31 – Updated: 2025-12-17 21:30A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sequoia 15.7.3. An app may be able to access sensitive user data.
{
"affected": [],
"aliases": [
"CVE-2025-43521"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-12T21:15:56Z",
"severity": "MODERATE"
},
"details": "A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sequoia 15.7.3. An app may be able to access sensitive user data.",
"id": "GHSA-cx5h-j8w3-whpr",
"modified": "2025-12-17T21:30:43Z",
"published": "2025-12-12T21:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43521"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125886"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125887"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F3Q4-GGFP-JV34
Vulnerability from github – Published: 2024-08-30 18:51 – Updated: 2024-08-30 18:51Adyen has utility methods for validating notification HMAC signatures. The is_valid_hmac and is_valid_hmac_notification methods are vulnerable to a timing attack, you should compare the hash of the HMACs instead.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Adyen"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "7.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-30T18:51:58Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Adyen has utility methods for validating notification HMAC signatures. The `is_valid_hmac` and `is_valid_hmac_notification` methods are vulnerable to a timing attack, you should compare the hash of the HMACs instead.",
"id": "GHSA-f3q4-ggfp-jv34",
"modified": "2024-08-30T18:51:58Z",
"published": "2024-08-30T18:51:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Adyen/adyen-python-api-library/issues/168"
},
{
"type": "WEB",
"url": "https://github.com/Adyen/adyen-python-api-library/pull/170"
},
{
"type": "WEB",
"url": "https://github.com/Adyen/adyen-python-api-library/commit/3292133dbc00ffc4cccfb92de672a76eaa587ca5"
},
{
"type": "PACKAGE",
"url": "https://github.com/Adyen/adyen-python-api-library"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/adyen/PYSEC-2023-1.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Adyen APIs Library for Python timing attack vulnerability"
}
GHSA-F3W5-V9XX-RP8P
Vulnerability from github – Published: 2021-12-20 18:17 – Updated: 2021-05-20 20:10The root cause of this security vulnerability is in the Tendermint specification, and this advisory is a duplicate of https://github.com/tendermint/spec/security/advisories/GHSA-jqfc-687g-59pw.
Impact
Tendermint light clients running versions 0.34.0 to 0.34.8 are unable to detect and punish a new kind of attack. We’re calling this a “forward lunatic attack,” or FLA. The severity of this vulnerability is moderate.
Note that an FLA cannot be successfully executed unless there are already ⅓+ Byzantine validators, and therefore outside of Tendermint’s security model; however, it is important to be able to detect and punish these kinds of attacks in order to incentivize correct behavior.
In an FLA, an attacking validator (with ⅓+ voting power) signs commit messages for arbitrary application state associated with a block height that hasn’t been seen yet, hence the name “forward lunatic attacks.” A malicious validator effectively executes a lunatic attack, but signs messages for a target block that is higher than the current block. This can be dangerous: Typically, misbehavior evidence is only created when there are conflicting blocks at the same height, but by targeting a block height that is far “ahead” of the current chain height, it’s possible that the chain will not produce a (conflicting) block at the target height in time to create evidence.
Prior to Tendermint v0.34.9, the light client could accept a bad header from its primary witness, and would not be able to form evidence of this deception, even if all the secondary witnesses were correct. Because the light client is responsible for verifying cross-chain state for IBC, a successful FLA could result in loss of funds. However, it is important to note that FLAs are only possible outside the Tendermint security model.
All FLAs, attempted and successful, leave traces of provable misbehavior on-chain. A faulty header contains signatures from the faulty validator, and even in unpatched versions of Tendermint Core, networks could use social consensus (off-chain action) to recover the network. The patches introduced in Tendermint Core v0.34.9 handle all evidence automatically and on-chain.
Note that this fix also allows for successful automatic reporting of FLAs, even after a chain halt. By adding a time to FetchBlock, light clients effectively have a backup way to determine if a halted chain should have continued, and it will be able to submit evidence as soon as the chain resumes.
Patches
This problem has been patched in Tendermint Core v0.34.9.
Workarounds
There are no workarounds. All users are recommended to upgrade to Tendermint Core v0.34.9 at their earliest possible convenience.
Credits
Thank you to @MaximilianDiez for originally surfacing this issue, and to @cmwaters, @josef-widder, and @milosevic for creating fixes at both the implementation and specification level.
For more information
If you have any questions or comments about this advisory: * Open an issue in tendermint/tendermint * Email us at security@tendermint.com
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tendermint/tendermint"
},
"ranges": [
{
"events": [
{
"introduced": "0.34.0"
},
{
"fixed": "0.34.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-20T20:10:47Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "_The root cause of this security vulnerability is in the Tendermint specification, and this advisory is a duplicate of https://github.com/tendermint/spec/security/advisories/GHSA-jqfc-687g-59pw._\n\n\n### Impact\nTendermint light clients running versions 0.34.0 to 0.34.8 are unable to detect and punish a new kind of attack. We\u2019re calling this a \u201cforward lunatic attack,\u201d or FLA. The severity of this vulnerability is _moderate_. \n\nNote that an FLA cannot be successfully executed unless there are already \u2153+ Byzantine validators, and therefore outside of Tendermint\u2019s security model; however, it is important to be able to detect and punish these kinds of attacks in order to incentivize correct behavior.\n\nIn an FLA, an attacking validator (with \u2153+ voting power) signs commit messages for arbitrary application state associated with a block height that hasn\u2019t been seen yet, hence the name \u201cforward lunatic attacks.\u201d A malicious validator effectively executes a [lunatic attack](https://docs.tendermint.com/master/spec/light-client/accountability/#the-misbehavior-of-faulty-validators), but signs messages for a target block that is higher than the current block. This can be dangerous: Typically, misbehavior evidence is only created when there are conflicting blocks at the same height, but by targeting a block height that is far \u201cahead\u201d of the current chain height, it\u2019s possible that the chain will not produce a (conflicting) block at the target height in time to create evidence. \n\nPrior to Tendermint v0.34.9, the light client could accept a bad header from its primary witness, and would not be able to form evidence of this deception, even if all the secondary witnesses were correct. Because the light client is responsible for verifying cross-chain state for IBC, a successful FLA could result in loss of funds. However, it is important to note that FLAs are only possible outside the Tendermint security model. \n\nAll FLAs, attempted and successful, leave traces of provable misbehavior on-chain. A faulty header contains signatures from the faulty validator, and even in unpatched versions of Tendermint Core, networks could use social consensus (off-chain action) to recover the network. The patches introduced in Tendermint Core v0.34.9 handle all evidence automatically and on-chain. \n\nNote that this fix also allows for successful automatic reporting of FLAs, even after a chain halt. By adding a time to FetchBlock, light clients effectively have a backup way to determine if a halted chain should have continued, and it will be able to submit evidence as soon as the chain resumes. \n\n### Patches\nThis problem has been patched in Tendermint Core v0.34.9. \n\n### Workarounds\nThere are no workarounds. All users are recommended to upgrade to Tendermint Core v0.34.9 at their earliest possible convenience. \n\n### Credits\n\nThank you to @MaximilianDiez for originally surfacing this issue, and to @cmwaters, @josef-widder, and @milosevic for creating fixes at both the implementation and specification level.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [tendermint/tendermint](https://github.com/tendermint/tendermint)\n* Email us at [security@tendermint.com](mailto:security@tendermint.com)",
"id": "GHSA-f3w5-v9xx-rp8p",
"modified": "2021-05-20T20:10:47Z",
"published": "2021-12-20T18:17:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tendermint/tendermint/security/advisories/GHSA-f3w5-v9xx-rp8p"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Signature verification failure in Tendermint"
}
No mitigation information available for this CWE.
CAPEC-463: Padding Oracle Crypto Attack
An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.