The sol macro in alloy is designed to generate type-safe Rust bindings for Ethereum smart contracts based on their ABI. However, the current implementation of the sol macro does not check for function selector collisions. This can result in the generation of bindings that contain multiple functions sharing the same function selector.
This vulnerability could be exploited by a malicious actor who provides an ABI containing colliding function selectors to an unsuspecting developer. The developer, unaware of the actual contract's ABI, might implement the bindings and call these functions, not realizing that both function calls are resolving to the same function selector. This could lead to unintended behavior in the application.
A simplified example of this issue can be seen when using a human-readable ABI format. The following functions, transfer(address,uint256) and func_2093253501(bytes), both share the same selector hash 0xa9059cbb (as seen on 4byte.directory):
sol! {
error func_2093253501(bytes);
error transfer(address,uint256);
function func_2093253501(bytes);
function transfer(address,uint256);
}
Moreover, the sol macro allows declaring errors that resolve to the selector hashes 0x00000000 and 0xffffffff. These selectors are reserved for future usage in Solidity, as mentioned in the docs. For example, the following code is not permitted by the Solidity compiler, because BlazingIt4490597615 () has the selector hash 0x00000000 as seen on 4byte.directory.
sol! {
error BlazingIt4490597615();
}
Expected Behavior
During compilation, an error should be raised pointing out occurrences of function selector collisions, as well as usage of illegal selector hashes.
Actual Behavior
No warnings or errors are produced. The code compiles successfully without alerting the developer to the selector collision.
Component
sol! macro
What version of Alloy are you on?
=0.7.6
Operating System
macOS (Apple Silicon)
Describe the bug
The
solmacro inalloyis designed to generate type-safe Rust bindings for Ethereum smart contracts based on their ABI. However, the current implementation of thesolmacro does not check for function selector collisions. This can result in the generation of bindings that contain multiple functions sharing the same function selector.This vulnerability could be exploited by a malicious actor who provides an ABI containing colliding function selectors to an unsuspecting developer. The developer, unaware of the actual contract's ABI, might implement the bindings and call these functions, not realizing that both function calls are resolving to the same function selector. This could lead to unintended behavior in the application.
A simplified example of this issue can be seen when using a human-readable ABI format. The following functions,
transfer(address,uint256)andfunc_2093253501(bytes), both share the same selector hash0xa9059cbb(as seen on 4byte.directory):Moreover, the
solmacro allows declaring errors that resolve to the selector hashes0x00000000and0xffffffff. These selectors are reserved for future usage in Solidity, as mentioned in the docs. For example, the following code is not permitted by the Solidity compiler, becauseBlazingIt4490597615 ()has the selector hash0x00000000as seen on 4byte.directory.Expected Behavior
During compilation, an error should be raised pointing out occurrences of function selector collisions, as well as usage of illegal selector hashes.
Actual Behavior
No warnings or errors are produced. The code compiles successfully without alerting the developer to the selector collision.