Closed code423n4 closed 2 years ago
The FeeBurner
doesn't hold any ETH as part of normal use. If someone randomly transfers ETH to the contract, it's fine if some random gets it.
The second call will fail as there will be no ETH to send to the SwapperRouter, for that reason I believe the finding to be invalid
Lines of code
https://github.com/code-423n4/2022-05-backd/blob/2a5664d35cde5b036074edef3c1369b984d10010/protocol/contracts/tokenomics/FeeBurner.sol#L56-L65
Vulnerability details
Impact
Attacker can drain all ETH from
FeeBurner.sol
. (Technicallymsg.value
gets sent toswapperRouter_
, but since this contract is out of scopeFeeBurner.sol
will be treated as the victim)Proof of Concept
FeeBurner.sol#L56-L65
Attacker can pass an
address[] memory tokens_
array containing multiple address(0). The samemsg.value
will be reused for every iteration, leading to the contract having to use its own balance to fulfil theswapAll
transactions.Example:
burnToTarget()
with 1 ether and inputs a token array[address(0),address(0),address(0)]
.for
loop (i = 0)swapperRouter_.swapAll{value: msg.value}(address(token_), _WETH);
will swap 1 ether forWETH
.for
loop (i = 1)swapperRouter_.swapAll()
will again use the samemsg.value
and swap another 1 ether forWETH
.WETH
that will be converted into the equivalent intargetLpToken_
.Attacker can make the token input array as big as necessary to drain all ether from contract.
Tools Used
Manual Review
Recommended Mitigation Steps
Implement a separate function for processing ether (or any other native token) and make sure the
msg.value
is not reused under afor
loop.