GHSA-x2c2-q32w-4w6m
Vulnerability from github
Summary
Vyper compiler allows passing a value in builtin raw_call
even if the call is a delegatecall
or a staticcall
. But in the context of delegatecall
and staticcall
the handling of value is not possible due to the semantics of the respective opcodes, and vyper will silently ignore the value=
argument.
A contract search was performed and no vulnerable contracts were found in production.
Details
The IR for raw_call
is built in the RawCall
class:
https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/builtins/functions.py#L1100
However, the compiler doesn't validate that if either delegatecall
or staticall
are provided as kwargs, that value
wasn't set. For example, the following compiles without errors:
python
raw_call(self, call_data2, max_outsize=255, is_delegate_call=True, value=msg.value/2)
Impact
If the semantics of the EVM are unknown to the developer, he could suspect that by specifying the value
kwarg, exactly the given amount will be sent along to the target. However in fact, no value
will be sent.
Here is an example of an potentially problematic implementation of multicall utilizing the raw_call
built-in:
python
value_accumulator: uint256 = empty(uint256)
results: DynArray[Result, max_value(uint8)] = []
return_data: Bytes[max_value(uint8)] = b""
success: bool = empty(bool)
for batch in data:
msg_value: uint256 = batch.value
value_accumulator = unsafe_add(value_accumulator, msg_value)
if (batch.allow_failure == False):
return_data = raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True)
success = True
results.append(Result({success: success, return_data: return_data}))
else:
success, return_data = \
raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True, revert_on_failure=False)
results.append(Result({success: success, return_data: return_data}))
assert msg.value == value_accumulator, "Multicall: value mismatch"
return results
Patches
Fixed in https://github.com/vyperlang/vyper/pull/3755
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?
{ "affected": [ { "package": { "ecosystem": "PyPI", "name": "vyper" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "0.4.0" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2024-24567" ], "database_specific": { "cwe_ids": [ "CWE-754" ], "github_reviewed": true, "github_reviewed_at": "2024-01-30T18:42:28Z", "nvd_published_at": "2024-01-30T21:15:08Z", "severity": "MODERATE" }, "details": "### Summary\nVyper compiler allows passing a value in builtin `raw_call` even if the call is a `delegatecall` or a `staticcall`. But in the context of `delegatecall` and `staticcall` the handling of value is not possible due to the semantics of the respective opcodes, and vyper will silently ignore the `value=` argument.\n\nA contract search was performed and no vulnerable contracts were found in production.\n\n### Details\nThe IR for `raw_call` is built in the `RawCall` class:\nhttps://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/builtins/functions.py#L1100\n\nHowever, the compiler doesn\u0027t validate that if either `delegatecall` or `staticall` are provided as kwargs, that `value` wasn\u0027t set. For example, the following compiles without errors:\n```python\nraw_call(self, call_data2, max_outsize=255, is_delegate_call=True, value=msg.value/2)\n```\n\n### Impact\nIf the semantics of the EVM are unknown to the developer, he could suspect that by specifying the `value` kwarg, exactly the given amount will be sent along to the target. However in fact, no `value` will be sent.\n\nHere is an example of an potentially problematic implementation of multicall utilizing the `raw_call` built-in:\n```python\nvalue_accumulator: uint256 = empty(uint256)\n results: DynArray[Result, max_value(uint8)] = []\n return_data: Bytes[max_value(uint8)] = b\"\"\n success: bool = empty(bool)\n for batch in data:\n msg_value: uint256 = batch.value\n value_accumulator = unsafe_add(value_accumulator, msg_value)\n if (batch.allow_failure == False):\n return_data = raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True)\n success = True\n results.append(Result({success: success, return_data: return_data}))\n else:\n success, return_data = \\\n raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True, revert_on_failure=False)\n results.append(Result({success: success, return_data: return_data}))\n assert msg.value == value_accumulator, \"Multicall: value mismatch\"\n return results\n```\n\n### Patches\nFixed in https://github.com/vyperlang/vyper/pull/3755\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", "id": "GHSA-x2c2-q32w-4w6m", "modified": "2024-11-22T20:46:32Z", "published": "2024-01-30T18:42:28Z", "references": [ { "type": "WEB", "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-x2c2-q32w-4w6m" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24567" }, { "type": "WEB", "url": "https://github.com/vyperlang/vyper/pull/3755" }, { "type": "WEB", "url": "https://github.com/vyperlang/vyper/commit/a2df08888c318713742c57f71465f32a1c27ed72" }, { "type": "WEB", "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2024-151.yaml" }, { "type": "PACKAGE", "url": "https://github.com/vyperlang/vyper" }, { "type": "WEB", "url": "https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/builtins/functions.py#L1100" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L", "type": "CVSS_V3" } ], "summary": "Vyper\u0027s raw_call `value=` kwargs not disabled for static and delegate calls" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.