Attackers can craft a malicious fallback handler with a clashing function selector to trick smart account owners into calling inbuilt functions.
Nexus smart accounts allows the owner to install fallback handlers which provide extensibility to the account, allowing additional functionality not present in the implementation to be added and called through the fallback
function.
Function dispatch in Solidity is done using function selectors. Selectors are represented by the first 4 bytes of the keccak hash of the function signature (name + argument types). It is possible (and not computationally difficult) to find different functions that have the same selector.
This means that a malicious actor can craft a fallback handler with a function signature carefully selected to match one of the functions present in the Nexus
contract, and with an innocent looking implementation. While the fallback implementation may seem harmless, this function when called will actually trigger the function in the Nexus
contract.
For example:
BaseAccount.withdrawDepositTo()
has the function signature of 0x4d44560d
Attacker creates a fallback handler with a function which also has a signature of 0x4d44560d
. This function looks harmless.
Owner of a Nexus
account installs the fallback handler using installModule()
.
Owner attempts to call the function in the fallback handler:
When his transaction is sent through the entrypoint contract, it ends up calling BaseAccount.withdrawDepositTo()
instead as it has the same function signature.
ETH is transferred out of the account to the to
address.
In this example, through the malicious fallback handler, the attacker tricks the owner into transferring ETH out of his Nexus
account.
This is similar to the exploit reported on proxies in this article, which caused the proposal of the transparent proxy pattern.
Owners of Nexus
accounts can be tricked into calling sensitive functions in Nexus
implementation, such as withdrawDepositTo()
.
Consider documenting that modules with clashing function selectors should not be installed or called.
Additionally, consider checking for these selectors in _installFallbackHandler()
and reverting if the owner attempts to install them.
This is a very clever exploit, however, would be dependent on - The user installing the malicious fallback handler. - Additionally, it is highly contraint because it would require the input parameters (`to` and `amount`) of `withdrawDepositTo()` that is also considered when determining the function signature to coincide with the same input parameters of the malicious functionality of the fallback handler Issues #185 and #190 are pointing to similar function clashing root causes so duplicating, but does lack a similar detailed explanation of exploit path.
This is a very clever exploit, however, would be dependent on - The user installing the malicious fallback handler. - Additionally, it is highly contraint because it would require the input parameters (`to` and `amount`) of `withdrawDepositTo()` that is also considered when determining the function signature to coincide with the same input parameters of the malicious functionality of the fallback handler Issues #185 and #190 are pointing to similar function clashing root causes so duplicating, but does lack a similar detailed explanation of exploit path.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.