Open code423n4 opened 1 year ago
gzeon-c4 marked the issue as duplicate of #90
gzeon-c4 marked the issue as not a duplicate
gzeon-c4 marked the issue as primary issue
once public will double check with infinitism community. marked acknowledged for now. and for multisend non-atomic does not make sense!
livingrockrises marked the issue as sponsor acknowledged
gzeon-c4 marked the issue as selected for report
Lines of code
https://github.com/code-423n4/2023-01-biconomy/blob/5df2e8f8c0fd3393b9ecdad9ef356955f07fbbdd/scw-contracts/contracts/smart-contract-wallet/aa-4337/core/EntryPoint.sol#L68 https://github.com/code-423n4/2023-01-biconomy/blob/5df2e8f8c0fd3393b9ecdad9ef356955f07fbbdd/scw-contracts/contracts/smart-contract-wallet/libs/MultiSend.sol#L26
Vulnerability details
Description
The
handleOps
function executes an array ofUserOperation
. If at least one user operation fails the whole transaction will revert. That means the error on one user ops will fully reverts the other executed ops.The
multiSend
function reverts if at least one of the transactions fails, so it is also vulnerable to such type of attacks.Attack scenario
Relayer offchain verify the batch of
UserOperation
s, convinced that they will receive fees, then send thehandleOps
transaction to the mempool. An attacker front-run the relayers transaction with anotherhandleOps
transaction that executes only oneUserOperation
, the last user operation from the relayershandleOps
operations. An attacker will receive the funds for oneUserOperation
. Original relayers transaction will consume gas for the execution of all except one, user ops, but reverts at the end.Impact
Griefing attacks on the gas used for
handleOps
andmultiSend
function calls.Please note, that while an attacker have no direct incentive to make such an attacks, they could short the token before the attack.
Recommended Mitigation Steps
Remove redundant
require
-like checks from internal functions called from thehandleOps
function and add the non-atomic execution logic to themultiSend
function.