{"id":"GHSA-f5x6-7qgp-jhf3","summary":"ecrecover can return undefined data if signature does not verify","details":"### Impact\nthe ecrecover precompile does not fill the output buffer if the signature does not verify, see https://github.com/ethereum/go-ethereum/blob/b058cf454b3bdc7e770e2b3cec83a0bcb48f55ee/core/vm/contracts.go#L188. however, the ecrecover builtin will still return whatever is at memory location 0.\n\nthis means that the if the compiler has been convinced to write to the 0 memory location with specially crafted data (generally, this can happen with a hashmap access or immutable read) just before the ecrecover, a signature check might pass on an invalid signature.\n\nA contract search was performed. Most uses of `ecrecover` are used for erc2612-style permit implementations, which typically look like:\n\n```vyper\n    assert _owner != empty(address)\n    assert block.timestamp \u003c= _deadline\n                  \n    nonce: uint256 = self.nonces[_owner]\n    digest: bytes32 = keccak256(\n        concat(   \n            b\"\\x19\\x01\",\n            self.DOMAIN_SEPARATOR,\n            keccak256(_abi_encode(PERMIT_TYPEHASH, _owner, _spender, _value, nonce, _deadline))\n        )         \n    )             \n    assert ecrecover(digest, convert(_v, uint256), convert(_r, uint256), convert(_s, uint256)) == _owner\n```\n\nin this case, the immutable `PERMIT_TYPEHASH` is loaded into `ecrecover`'s output buffer right before `ecrecover()`, and so the output of `ecrecover()` here when the signature is invalid will be the value of `PERMIT_TYPEHASH`. in this case, since `PERMIT_TYPEHASH` is not a valid address, it will never compare `==` to `_owner`, and so the behaviour is exactly the same as if `ecrecover()` returned 0 in this case.\n\nin general, a contract could have unexpected behavior (i.e. mistakenly pass this style of signature check) if an immutable representing a real address (ex. `OWNER`) was read right before the `ecrecover` operation.\n\n### Patches\nv0.3.10 (with 019a37ab98ff53f04fecfadf602b6cd5ac748f7f and #3586)\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_\n","aliases":["CVE-2023-37902","PYSEC-2023-133"],"modified":"2024-11-19T17:01:17.067007Z","published":"2023-07-25T17:46:19Z","database_specific":{"nvd_published_at":"2023-07-25T21:15:10Z","github_reviewed_at":"2023-07-25T17:46:19Z","github_reviewed":true,"cwe_ids":["CWE-252"],"severity":"MODERATE"},"references":[{"type":"WEB","url":"https://github.com/vyperlang/vyper/security/advisories/GHSA-f5x6-7qgp-jhf3"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-37902"},{"type":"WEB","url":"https://github.com/vyperlang/vyper/commit/019a37ab98ff53f04fecfadf602b6cd5ac748f7f"},{"type":"WEB","url":"https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-133.yaml"},{"type":"PACKAGE","url":"https://github.com/vyperlang/vyper"}],"affected":[{"package":{"name":"vyper","ecosystem":"PyPI","purl":"pkg:pypi/vyper"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.3.10"}]}],"versions":["0.1.0b1","0.1.0b10","0.1.0b11","0.1.0b12","0.1.0b13","0.1.0b14","0.1.0b15","0.1.0b16","0.1.0b17","0.1.0b2","0.1.0b3","0.1.0b4","0.1.0b5","0.1.0b6","0.1.0b7","0.1.0b8","0.1.0b9","0.2.1","0.2.10","0.2.11","0.2.12","0.2.13","0.2.14","0.2.15","0.2.16","0.2.2","0.2.3","0.2.4","0.2.5","0.2.6","0.2.7","0.2.8","0.2.9","0.3.0","0.3.1","0.3.10rc1","0.3.10rc2","0.3.10rc3","0.3.10rc4","0.3.10rc5","0.3.2","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.3.9"],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2023/07/GHSA-f5x6-7qgp-jhf3/GHSA-f5x6-7qgp-jhf3.json"}}],"schema_version":"1.7.3","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"},{"type":"CVSS_V4","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"}]}