GHSA-375m-5fvv-xq23

Dashboard / Vulnerabilities / GHSA-375m-5fvv-xq23

GHSA-375m-5fvv-xq23

Summary: VVE-2021-0002: Incorrect `returndatasize` when using simple forwarder proxies deployed prior to EIP-1167 adoption

Details: ## Background @tjayrush reported a data handling issue with certain Web3 libraries using Vyper-deploy forwarder proxy contracts using our Vyper's built-in `create_forwarder_to` function prior to our change to support EIP-1167 style forwarder proxies. ### Impact If you are an end user of a forwarder-style proxy deployed using Vyper's built-in `create_forwarder_to` function AND you have a function that returns >4096 bytes AND you do no return data sanitation on the value returned, you could potentially see a data corruption issue. Otherwise, if you are handling the result of a return call AND you expect a specific `RETURNDATASIZE` that is less than 4096 (such as `SafeERC20.safeTransfer`) then the call will fail that check. ### Patches The issue was patched when we upgraded to EIP-1167 style forwarder proxies in #2281. ### Workarounds If you are making a call to a contract method that is expected to return <= 4096 bytes, there is no issue as the ABI decoders in both Solidity and Vyper will truncate the data properly. Web3 libraries will also do this, unless you are doing `eth_call` or `eth_sendTransaction` directly. If you are using a Solidity library that checks `RETURNDATASIZE` of an external call to a forwarder proxy deployed prior to this patch, it will fail on that assertion (such as `SafeERC20.safeTransfer`). The workaround is to always do a greater than or equal to check, rather than a strict equals to check.

References: https://github.com/vyperlang/vyper/security/advisories/GHSA-375m-5fvv-xq23, https://github.com/vyperlang/vyper/pull/2281, https://pypi.org/project/vyper