NestedFactory: User can utilise accidentally sent ETH funds via processOutputOrders() / processInputAndOutputOrders() #44
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Lines of code
https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L71
https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L286-L296
https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L370-L375
https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L482-L492
Vulnerability details
Impact
Should a user accidentally send ETH to the
NestedFactory
, anyone can utilise it to their own benefit by callingprocessOutputOrders()
/processInputAndOutputOrders()
. This is possible because:receive()
has no restriction on the senderprocessOutputOrders()
does not checkmsg.value
, and rightly so, because funds are expected to come fromreserve
.transferInputTokens()
does not handle the case whereETH
could be specified as an address by the user for an output order.Hence, the attack vector is simple. Should a user accidentally send ETH to the contract, create an output
Order
withtoken
beingETH
and amount corresponding to the NestedFactory’s ETH balance.Recommended Mitigation Steps
Since plain / direct
ETH
transfers are only expected to solely come fromweth
(excluding payable functions), we recommend restricting the sender to beweth
, like how it is done in[FeeSplitter](https://github.com/code-423n4/2022-02-nested/blob/main/contracts/FeeSplitter.sol#L101-L104)
.We are aware that this was raised previously here: Restrict funds receivable to be only from wrapped native token 2021-11-nested-findings#188 and would like to add that the restricting the sender in the
receive()
function will not affectpayable
functions. From from what we see, plain ETH transfers are also not expected to come from other sources likeNestedReserve
or operators._fromReserve
is false in the scenarioaddress(_inputToken) == ETH
.The text was updated successfully, but these errors were encountered: