Headline
GHSA-cx2q-hfxr-rj97: Vyper's `_abi_decode` input not validated in complex expressions
Impact
_abi_decode() does not validate input when it is nested in an expression. the following example gets correctly validated (bounds checked):
x: int128 = _abi_decode(slice(msg.data, 4, 32), int128)
however, the following example is not bounds checked
@external
def abi_decode(x: uint256) -> uint256:
a: uint256 = convert(_abi_decode(slice(msg.data, 4, 32), (uint8)), uint256) + 1
return a # abi_decode(256) returns: 257
the issue can be triggered by constructing an example where the output of _abi_decode is not internally passed to make_setter (an internal codegen routine) or other input validating routine.
Patches
https://github.com/vyperlang/vyper/pull/3626
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?
Impact
_abi_decode() does not validate input when it is nested in an expression. the following example gets correctly validated (bounds checked):
x: int128 = _abi_decode(slice(msg.data, 4, 32), int128)
however, the following example is not bounds checked
@external def abi_decode(x: uint256) -> uint256: a: uint256 = convert(_abi_decode(slice(msg.data, 4, 32), (uint8)), uint256) + 1 return a # abi_decode(256) returns: 257
the issue can be triggered by constructing an example where the output of _abi_decode is not internally passed to make_setter (an internal codegen routine) or other input validating routine.
Patches
vyperlang/vyper#3626
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?
References
- GHSA-cx2q-hfxr-rj97
Related news
Vyper is a Pythonic Smart Contract Language for the EVM. The `_abi_decode()` function does not validate input when it is nested in an expression. Uses of `_abi_decode()` can be constructed which allow for bounds checking to be bypassed resulting in incorrect results. This issue has not yet been fixed, but a fix is expected in release `0.3.10`. Users are advised to reference pull request #3626.