Ecosyste.ms: Advisories

An open API service providing security vulnerability metadata for many open source software ecosystems.

Security Advisories: GSA_kwCzR0hTQS1mNXg2LTdxZ3AtamhmM84AA04g

ecrecover can return undefined data if signature does not verify

Impact

the 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.

this 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.

A contract search was performed. Most uses of ecrecover are used for erc2612-style permit implementations, which typically look like:

    assert _owner != empty(address)
    assert block.timestamp <= _deadline
                  
    nonce: uint256 = self.nonces[_owner]
    digest: bytes32 = keccak256(
        concat(   
            b"\x19\x01",
            self.DOMAIN_SEPARATOR,
            keccak256(_abi_encode(PERMIT_TYPEHASH, _owner, _spender, _value, nonce, _deadline))
        )         
    )             
    assert ecrecover(digest, convert(_v, uint256), convert(_r, uint256), convert(_s, uint256)) == _owner

in 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.

in 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.

Patches

v0.3.10 (with 019a37ab98ff53f04fecfadf602b6cd5ac748f7f and #3586)

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Permalink: https://github.com/advisories/GHSA-f5x6-7qgp-jhf3
JSON: https://advisories.ecosyste.ms/api/v1/advisories/GSA_kwCzR0hTQS1mNXg2LTdxZ3AtamhmM84AA04g
Source: GitHub Advisory Database
Origin: Unspecified
Severity: Moderate
Classification: General
Published: 10 months ago
Updated: 7 months ago


CVSS Score: 5.3
CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Identifiers: GHSA-f5x6-7qgp-jhf3, CVE-2023-37902
References: Repository: https://github.com/vyperlang/vyper
Blast Radius: 12.6

Affected Packages

pypi:vyper
Dependent packages: 5
Dependent repositories: 236
Downloads: 37,124 last month
Affected Version Ranges: < 0.3.10
Fixed in: 0.3.10
All affected versions: 0.2.1, 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.2.10, 0.2.11, 0.2.12, 0.2.13, 0.2.14, 0.2.15, 0.2.16, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9
All unaffected versions: 0.3.10