Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1120 vulnerabilities reference this CWE, most recent first.

GHSA-WGJG-8JRW-H95F

Vulnerability from github – Published: 2022-05-17 00:17 – Updated: 2022-05-17 00:17
VLAI
Details

FusionSphere OpenStack V100R006C00SPC102(NFV)has an improper verification of cryptographic signature vulnerability. The software does not verify the cryptographic signature. An attacker with high privilege may exploit this vulnerability to inject malicious software.

Severity
6.7 (Medium)
CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-8190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-22T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "FusionSphere OpenStack V100R006C00SPC102(NFV)has an improper verification of cryptographic signature vulnerability. The software does not verify the cryptographic signature. An attacker with high privilege may exploit this vulnerability to inject malicious software.",
  "id": "GHSA-wgjg-8jrw-h95f",
  "modified": "2022-05-17T00:17:08Z",
  "published": "2022-05-17T00:17:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8190"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171018-01-fusionsphere-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WH2W-39F4-RPV2

Vulnerability from github – Published: 2024-08-30 18:41 – Updated: 2024-08-30 18:41
VLAI
Summary
Hyperledger Indy's update process of a DID does not check who signs the request
Details

Name

Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender.

Description

A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because: 1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions). 1. Any DID can change any other DID's alias. 1. The update transaction modifies the ledger metadata associated with a DID.

Expected vs Observed

We expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the Indy default auth_rules in Section "Who is the owner" in the last point of "Endorser using".

We observe that with a normal DID, we can update the field from for a random DID, for example, the one of a TRUSTEE. It creates then a new transaction on the ledger.

Explanation of the attack

We first begin to connect to the pool and open a wallet. Then, we will use a TRUSTEE (but can also be a STEWARD or an ENDORSER) DID V4SGRU86Z58d6TV7PBUe6f. We ask the information about V4SGRU86Z58d6TV7PBUe6f with a get-nym. We create a new DID V4SGRU86Z58d6TV7PBUe1a signed by V4SGRU86Z58d6TV7PBUe6f with no role. For the rest of the attack, we will use V4SGRU86Z58d6TV7PBUe1a to sign new transactions. We send a ledger nym did=V4SGRU86Z58d6TV7PBUe6f extra=hello to see if V4SGRU86Z58d6TV7PBUe1a can send an update of a TRUSTEE identity. When we ask information to the ledger about V4SGRU86Z58d6TV7PBUe6f, it answers that the from field is V4SGRU86Z58d6TV7PBUe1a (to compare with the first get-nym we did with from field = V4SGRU86Z58d6TV7PBUe6f). To see the log of the attack, I modified my indy-cli to print the json request and the json response directly on the terminal. You can find the log file indy.log in this archive.

Implementation notes

NymHandler method update_state, line 62. I think that we need to check if the DID which signs the transaction, owns the DID or is its endorser.

Steps to Reproduce

Environment

Ubuntu 18.04 Docker version 19.03.8 indy-cli indy-ci Dockerfile is copied in this archive To install indy-cli, run ./install_indy_cli.sh

Command

Here is the script to create the container, run the attack and remove the container and the image. Find below the command to execute each step separately.

./full_attack.sh

Installation of the environment

Install indy-cli and create an image with tag test from Dockerfile

./install.sh

Exploit

indy-cli proof_of_concept

Uninstallation of the environment

Suppress the container test and remove the image test

./uninstall.sh

Analysis

We are grateful to @alexandredeleze for discovering and responsibly disclosing the issue.

We were previously aware that any DID on the ledger can "update" the state (seqNo + txnTime) if it doesn't change the state data itself. We considered this a minor bug because only the seqNo and txnTime changed. But seeing that this can also affect the "parent" DID means that it has a higher severity.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "indy-node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-11093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-30T18:41:16Z",
    "nvd_published_at": "2020-12-24T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "# Name\nUpdating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender.\n\n# Description\nA malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because:\n1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions).\n1. Any DID can change any other DID\u0027s alias. \n1. The update transaction modifies the ledger metadata associated with a DID. \n\n# Expected vs Observed\nWe expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the [Indy default auth_rules](https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md) in Section \"Who is the owner\" in the last point of \"Endorser using\". \n\nWe observe that with a normal DID, we can update the field `from` for a random DID, for example, the one of a TRUSTEE. It creates then a new transaction on the ledger.\n\n# Explanation of the attack\nWe first begin to connect to the pool and open a wallet. Then, we will use a TRUSTEE (but can also be a STEWARD or an ENDORSER) DID `V4SGRU86Z58d6TV7PBUe6f`. We ask the information about `V4SGRU86Z58d6TV7PBUe6f` with a get-nym. We create a new DID `V4SGRU86Z58d6TV7PBUe1a` signed by `V4SGRU86Z58d6TV7PBUe6f` with no role. For the rest of the attack, we will use `V4SGRU86Z58d6TV7PBUe1a` to sign new transactions. We send a `ledger nym did=V4SGRU86Z58d6TV7PBUe6f extra=hello` to see if `V4SGRU86Z58d6TV7PBUe1a` can send an update of a TRUSTEE identity. When we ask information to the ledger about `V4SGRU86Z58d6TV7PBUe6f`, it answers that the `from` field is `V4SGRU86Z58d6TV7PBUe1a` (to compare with the first get-nym we did with `from` field = `V4SGRU86Z58d6TV7PBUe6f`). To see the log of the attack, I modified my indy-cli to print the json request and the json response directly on the terminal. You can find the log file `indy.log` in this archive.\n\n# Implementation notes\n[NymHandler](https://github.com/hyperledger/indy-node/blob/e5676b703d625e42c9547333bd03bb8307ed534c/indy_node/server/request_handlers/domain_req_handlers/nym_handler.py) method `update_state`, line 62. I think that we need to check if the DID which signs the transaction, owns the DID or is its endorser.\n\n# Steps to Reproduce\n\n## Environment\nUbuntu 18.04\nDocker version 19.03.8\n[indy-cli](https://github.com/hyperledger/indy-sdk/tree/master/cli)\n[indy-ci](https://github.com/hyperledger/indy-sdk/tree/master/ci) Dockerfile is copied in this archive\nTo install indy-cli, run `./install_indy_cli.sh`\n\n\n## Command\nHere is the script to create the container, run the attack and remove the container and the image. Find below the command to execute each step separately.\n```\n./full_attack.sh\n```\n\n### Installation of the environment\nInstall indy-cli and create an image with tag `test` from Dockerfile\n```\n./install.sh\n```\n\n### Exploit\n```\nindy-cli proof_of_concept\n```\n\n### Uninstallation of the environment\nSuppress the container `test` and remove the image `test`\n```\n./uninstall.sh\n```\n# Analysis\nWe are grateful to @alexandredeleze for discovering and responsibly disclosing the issue.\n\nWe were previously aware that any DID on the ledger can \"update\" the state (seqNo + txnTime) if it doesn\u0027t change the state data itself. We considered this a minor bug because only the seqNo and txnTime changed. But seeing that this can also affect the \"parent\" DID means that it has a higher severity.",
  "id": "GHSA-wh2w-39f4-rpv2",
  "modified": "2024-08-30T18:41:16Z",
  "published": "2024-08-30T18:41:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/indy-node/security/advisories/GHSA-wh2w-39f4-rpv2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11093"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/indy-node/commit/55056f22c83b7c3520488b615e1577e0f895d75a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hyperledger/indy-node"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/indy-node/blob/master/CHANGELOG.md#1124"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/indy-node/PYSEC-2020-48.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hyperledger Indy\u0027s update process of a DID does not check who signs the request"
}

GHSA-WJ3M-9V78-X5G4

Vulnerability from github – Published: 2022-05-14 01:48 – Updated: 2022-05-14 01:48
VLAI
Details

In sig_verify() in x509.c in axTLS version 2.1.3 and before, the PKCS#1 v1.5 signature verification does not reject excess data after the hash value. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation through fake X.509 certificates. This is a variant of CVE-2006-4340.

Severity
5.9 (Medium)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-16150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-11-07T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "In sig_verify() in x509.c in axTLS version 2.1.3 and before, the PKCS#1 v1.5 signature verification does not reject excess data after the hash value. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation through fake X.509 certificates. This is a variant of CVE-2006-4340.",
  "id": "GHSA-wj3m-9v78-x5g4",
  "modified": "2022-05-14T01:48:57Z",
  "published": "2022-05-14T01:48:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16150"
    },
    {
      "type": "WEB",
      "url": "https://github.com/igrr/axtls-8266/commit/5efe2947ab45e81d84b5f707c51d1c64be52f36c"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/p/axtls/mailman/message/36459928"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WJMP-WPHQ-JVQF

Vulnerability from github – Published: 2025-05-06 21:18 – Updated: 2025-05-06 21:43
VLAI
Summary
Passport-wsfed-saml2 allows SAML Authentication Bypass via Signature Wrapping
Details

Overview

This vulnerability allows an attacker to impersonate any user during SAML authentication by crafting a SAMLResponse. This can be done by using a valid SAML object that was signed by the configured IdP.

Am I Affected?

You are affected by this SAML Signature Wrapping vulnerability if you are using passport-wsfed-saml2 version 4.6.3 or below, specifically under the following conditions: 1. The service provider is using passport-wsfed-saml2, 2. A valid SAML document signed by the Identity Provider can be obtained.

Fix

Upgrade to v4.6.4 or greater.

Severity
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "passport-wsfed-saml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.5"
            },
            {
              "fixed": "4.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-06T21:18:43Z",
    "nvd_published_at": "2025-05-06T21:16:20Z",
    "severity": "CRITICAL"
  },
  "details": "### Overview\nThis vulnerability allows an attacker to impersonate any user during SAML authentication by crafting a SAMLResponse. This can be done by using a valid SAML object that was signed by the configured IdP.\n\n### Am I Affected?\nYou are affected by this SAML Signature Wrapping vulnerability if you are using `passport-wsfed-saml2` version 4.6.3 or below, specifically under the following conditions:\n1. The service provider is using `passport-wsfed-saml2`,\n2. A valid SAML document signed by the Identity Provider can be obtained.\n\n### Fix\nUpgrade to v4.6.4 or greater.",
  "id": "GHSA-wjmp-wphq-jvqf",
  "modified": "2025-05-06T21:43:47Z",
  "published": "2025-05-06T21:18:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/passport-wsfed-saml2/security/advisories/GHSA-wjmp-wphq-jvqf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46572"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/passport-wsfed-saml2/commit/e5cf3cc2a53748207f7a81bfba9195c8efa94181"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/passport-wsfed-saml2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Passport-wsfed-saml2 allows SAML Authentication Bypass via Signature Wrapping"
}

GHSA-WJVM-2XMX-5VHG

Vulnerability from github – Published: 2024-07-10 21:30 – Updated: 2024-07-10 21:30
VLAI
Details

An improper file signature check in Palo Alto Networks Cortex XDR agent may allow an attacker to bypass the Cortex XDR agent's executable blocking capabilities and run untrusted executables on the device. This issue can be leveraged to execute untrusted software without being detected or blocked.

Severity
6.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/AU:N/R:U/V:C/RE:M/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-5912"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-10T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "An improper file signature check in Palo Alto Networks Cortex XDR agent may allow an attacker to bypass the Cortex XDR agent\u0027s executable blocking capabilities and run untrusted executables on the device. This issue can be leveraged to execute untrusted software without being detected or blocked.",
  "id": "GHSA-wjvm-2xmx-5vhg",
  "modified": "2024-07-10T21:30:38Z",
  "published": "2024-07-10T21:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5912"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2024-5912"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/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:N/R:U/V:C/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-WMMR-FRFJ-GMMW

Vulnerability from github – Published: 2023-02-06 15:30 – Updated: 2025-03-26 21:30
VLAI
Details

Western Digital My Cloud devices before OS5 do not use cryptographically signed Firmware upgrade files.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-36226"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-06T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Western Digital My Cloud devices before OS5 do not use cryptographically signed Firmware upgrade files.",
  "id": "GHSA-wmmr-frfj-gmmw",
  "modified": "2025-03-26T21:30:44Z",
  "published": "2023-02-06T15:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36226"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pedrib/PoC/blob/master/advisories/Pwn2Own/Tokyo_2020/weekend_destroyer/weekend_destroyer.md"
    },
    {
      "type": "WEB",
      "url": "https://krebsonsecurity.com/2021/07/another-0-day-looms-for-many-western-digital-users"
    },
    {
      "type": "WEB",
      "url": "https://www.youtube.com/watch?v=vsg9YgvGBec"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WMQC-JFC8-PFM5

Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2024-11-27 21:32
VLAI
Details

The Portable Document Format (PDF) specification does not provide any information regarding the concrete procedure of how to validate signatures. Consequently, a Signature Wrapping vulnerability exists in multiple products. An attacker can use /ByteRange and xref manipulations that are not detected by the signature-validation logic. This affects Foxit Reader before 9.4 and PhantomPDF before 8.3.9 and 9.x before 9.4. It also affects eXpert PDF 12 Ultimate, Expert PDF Reader, Nitro Pro, Nitro Reader, PDF Architect 6, PDF Editor 6 Pro, PDF Experte 9 Ultimate, PDFelement6 Pro, PDF Studio Viewer 2018, PDF Studio Pro, PDF-XChange Editor and Viewer, Perfect PDF 10 Premium, Perfect PDF Reader, Soda PDF, and Soda PDF Desktop.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-18689"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-07T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Portable Document Format (PDF) specification does not provide any information regarding the concrete procedure of how to validate signatures. Consequently, a Signature Wrapping vulnerability exists in multiple products. An attacker can use /ByteRange and xref manipulations that are not detected by the signature-validation logic. This affects Foxit Reader before 9.4 and PhantomPDF before 8.3.9 and 9.x before 9.4. It also affects eXpert PDF 12 Ultimate, Expert PDF Reader, Nitro Pro, Nitro Reader, PDF Architect 6, PDF Editor 6 Pro, PDF Experte 9 Ultimate, PDFelement6 Pro, PDF Studio Viewer 2018, PDF Studio Pro, PDF-XChange Editor and Viewer, Perfect PDF 10 Premium, Perfect PDF Reader, Soda PDF, and Soda PDF Desktop.",
  "id": "GHSA-wmqc-jfc8-pfm5",
  "modified": "2024-11-27T21:32:36Z",
  "published": "2022-05-24T17:38:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18689"
    },
    {
      "type": "WEB",
      "url": "https://pdf-insecurity.org/signature/evaluation_2018.html"
    },
    {
      "type": "WEB",
      "url": "https://pdf-insecurity.org/signature/signature.html"
    },
    {
      "type": "WEB",
      "url": "https://www.foxitsoftware.com/support/security-bulletins.php"
    },
    {
      "type": "WEB",
      "url": "https://www.pdfa.org/recently-identified-pdf-digital-signature-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WPP8-9P7M-8GX2

Vulnerability from github – Published: 2024-11-05 12:31 – Updated: 2024-11-05 12:31
VLAI
Details

Permission control vulnerability in the hidebug module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Severity
8.2 (High)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-51526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-05T10:21:14Z",
    "severity": "HIGH"
  },
  "details": "Permission control vulnerability in the hidebug module\nImpact: Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-wpp8-9p7m-8gx2",
  "modified": "2024-11-05T12:31:03Z",
  "published": "2024-11-05T12:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51526"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2024/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WV7Q-JRQ7-C9JQ

Vulnerability from github – Published: 2024-12-03 06:30 – Updated: 2024-12-03 06:30
VLAI
Details

Improper Verification of Cryptographic Signature in SmartSwitch prior to SMR Dec-2024 Release 1 allows local attackers to install malicious applications.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-49413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-03T06:15:09Z",
    "severity": "HIGH"
  },
  "details": "Improper Verification of Cryptographic Signature in SmartSwitch prior to SMR Dec-2024 Release 1 allows local attackers to install malicious applications.",
  "id": "GHSA-wv7q-jrq7-c9jq",
  "modified": "2024-12-03T06:30:55Z",
  "published": "2024-12-03T06:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49413"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WVC4-J7G5-4F79

Vulnerability from github – Published: 2023-03-27 21:12 – Updated: 2023-03-27 21:12
VLAI
Summary
NATS TLS certificate common name validation bypass
Details

The NATS official Rust clients are vulnerable to MitM when using TLS.

A fix for the nats crate hasn't been released yet. Since the nats crate is going to be deprecated anyway, consider switching to async-nats >= 0.29 which already fixed this vulnerability.

The common name of the server's TLS certificate is validated against the hostname provided by the server's plaintext INFO message during the initial connection setup phase. A MitM proxy can tamper with the host field's value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it.

Reproduction steps

  1. The NATS Rust client tries to establish a new connection
  2. The connection is intercepted by a MitM proxy
  3. The proxy makes a separate connection to the NATS server
  4. The NATS server replies with an INFO message
  5. The proxy reads the INFO, alters the host JSON field and passes the tampered INFO back to the client
  6. The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client's keychain. In the previous step the host was set to the common name of said certificate
  7. rustls accepts the certificate, having verified that the common name matches the attacker-controlled value it was given
  8. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.24.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "nats"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.24.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-27T21:12:24Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "The NATS official Rust clients are vulnerable to MitM when using TLS.\n\nA fix for the `nats` crate hasn\u0027t been released yet. Since the `nats` crate is going to be deprecated anyway, consider switching to `async-nats` `\u003e= 0.29` which already fixed this vulnerability.\n\nThe common name of the server\u0027s TLS certificate is validated against the `host`name provided by the server\u0027s plaintext `INFO` message during the initial connection setup phase. A MitM proxy can tamper with the `host` field\u0027s value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it.\n\n## Reproduction steps\n\n1. The NATS Rust client tries to establish a new connection\n2. The connection is intercepted by a MitM proxy\n3. The proxy makes a separate connection to the NATS server\n4. The NATS server replies with an `INFO` message\n5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client\n6. The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client\u0027s keychain. In the previous step the `host` was set to the common name of said certificate\n7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given\n9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate\n",
  "id": "GHSA-wvc4-j7g5-4f79",
  "modified": "2023-03-27T21:12:24Z",
  "published": "2023-03-27T21:12:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats.rs/pull/881"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats.rs/pull/887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats.rs/commit/9bacb86a480803ece9d1a45aa443081cf1eb815c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/nats.rs"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0029.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "NATS TLS certificate common name validation bypass"
}

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.

← Back to the CWE list