Functions in fallback handlers with the same signature as functions in the Nexus
implementation or onERC721Received()
, onERC1155Received()
and onERC1155BatchReceived()
can never be used.
In ModuleManager.sol
, the fallback function calls the receiverFallback
modifier:
The receiverFallback
modifier checks if the first 4 bytes (ie. msg.sig
) of the calldata is equal to the function signature of onERC721Received()
, onERC1155Received()
and onERC1155BatchReceived()
, and simply returns if so:
If a Nexus
account is called with any of these function signatures, it will simply return.
Therefore, if a fallback handler module has a function that happens to have the same signature as those listed above, it cannot be used as that function cannot be called through the fallback
function.
Additionally, functions with signatures that clashes with functions in the Nexus
implementation cannot be used as well.
Fallback handlers that have functions with clashing signatures cannot be used by Nexus
accounts.
Consider implementing the functionality of receiverFallback
as a fallback handler instead, which gives Nexus
account owners the option to opt-out of such functionality.
Additionally, document that functions with signatures that clash with functions in the Nexus
implementation cannot be called through the fallback
function.
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.