GHSA-HJ49-H7FQ-PX5H

Vulnerability from github – Published: 2025-01-30 19:28 – Updated: 2025-01-30 21:36
VLAI?
Summary
Soundness issue with Plonky2 look up tables
Details

Impact

Lookup tables, whose length is not divisible by 26 = floor(num_routed_wires / 3) always include the 0 -> 0 input-output pair. Thus a malicious prover can always prove that f(0) = 0 for any lookup table f (unless its length happens to be divisible by 26).

The cause of problem is that the LookupTableGate-s are padded with zeros.

The fix is done by padding with an existing table pair, similarly to LookupGate.

A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26.

Fortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable:

  • both Monolith's and Tip5/Tip4's s-box tables already map 0 to 0;
  • more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace.

A malicious prover exploiting this could cheat a circuit which statement is the following: - output x + f(x) for some private input x, where f(x) := 100 - x is implemented by a lookup table.

A malicious prover would be able to convince an honest verifier that they know an 0 <= x < 64 such that x + (100 - x) = 0.

Patches

Yes, upgrade to v1.0.1

Workarounds

No

References

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "plonky2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1240"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-30T19:28:51Z",
    "nvd_published_at": "2025-01-30T20:15:51Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nLookup tables, whose length is not divisible by `26 = floor(num_routed_wires / 3)` always include the `0 -\u003e 0` input-output pair. Thus a malicious prover can always prove that `f(0) = 0` for any lookup table f (unless its length happens to be divisible by 26).\n\nThe cause of problem is that the `LookupTableGate`-s are [padded with zeros](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97).\n\nThe fix is done by padding with an existing table pair, similarly to `LookupGate`.\n\nA workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26.\n\nFortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable:\n\n* both Monolith\u0027s and Tip5/Tip4\u0027s s-box tables already map 0 to 0;\n* more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace.\n\nA malicious prover exploiting this could cheat a circuit which statement is the following:\n- output `x + f(x)` for some private input `x`, where `f(x) := 100 - x` is implemented by a lookup table.\n\nA malicious prover would be able to convince an honest verifier that they know an `0 \u003c= x \u003c 64` such that `x + (100 - x) = 0`.\n\n### Patches\nYes, upgrade to v1.0.1\n\n### Workarounds\nNo\n\n### References\n\n",
  "id": "GHSA-hj49-h7fq-px5h",
  "modified": "2025-01-30T21:36:51Z",
  "published": "2025-01-30T19:28:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xPolygonZero/plonky2/security/advisories/GHSA-hj49-h7fq-px5h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xPolygonZero/plonky2/commit/091047f7f10cae082716f3738ad59a583835f7b6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xPolygonZero/plonky2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Soundness issue with Plonky2 look up tables"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.