Vyper: incorrect order of evaluation of side effects for some builtins

Vulnerability

CVE-2023-41052 describes an evaluation order vulnerability in the Vyper smart contract language, affecting the builtin functions uint256_addmod, uint256_mulmod, ecadd, and ecmul. The root cause is that the compiler does not evaluate the arguments of these functions in the order they appear in source code. Specifically, for uint256_addmod(a,b,c) and uint256_mulmod(a,b,c), the actual evaluation order is c, a, b, while for ecadd(a,b) and ecmul(a,b), the order is b, a [1][4].

Exploitation

This behavior becomes exploitable when the evaluation of one argument produces side effects that another argument depends on. For example, if a contract calls a function that modifies state as part of an argument expression, the unexpected evaluation order could lead to incorrect state changes or reentrancy-like conditions. An attacker can craft transactions that rely on the compiler's unintended evaluation sequence to manipulate contract logic, potentially draining funds or corrupting data [1][4].

Impact

An attacker who can control the arguments passed to these builtins, or influence contract state during argument evaluation, may cause the smart contract to behave differently than intended. This could include bypassing access controls, altering arithmetic results, or triggering unintended state transitions. Since smart contracts often manage valuable assets, such inconsistencies can lead to financial loss [1][4].

Mitigation

The Vyper team is developing a patch in pull request #3583. As a workaround, developers should ensure that no argument expression for these builtins produces side effects, or if one does, that no other argument depends on those side effects. Users should review contracts using these functions and refactor code to avoid side-effect dependencies until the patch is released [1][4].