Escher contest - asgeir's results

Lines of code

https://github.com/code-423n4/2022-12-escher/blob/5d8be6aa0e8634fdb2f328b99076b0d05fefab73/src/minters/LPDA.sol#L86

Vulnerability details

Impact

After a mint sale using LPDA, all the Ether can be locked in the LPDA contract indefinitely.

Proof of Concept

In the src/minters/* contracts, the .transfer() function is used for sending Ether. It is used for sending fees to the feeReceiver, and in the src/minters/LPDA.sol contract, it is also used for sending Ether to the saleReceiver.

In both cases, this transfer function will revert if the receiving address is for a contract with a receive (or fallback function if there are no receive functions) that uses more than 2300 gas or, for other reasons, fail.

In the case of transfers to the feeReceiver, it would be possible to set a new feeRecever (via the setFeeReceiver function in the factory). However, in the case of the transfers to the saleReceiver reverting, there is no redemption since the saleReceiver can not be changed. Also, this could likely not be discovered before the sale of the final NFT. In this case, the Ether will be locked in the contract indefinitely. https://github.com/code-423n4/2022-12-escher/blob/5d8be6aa0e8634fdb2f328b99076b0d05fefab73/src/minters/LPDA.sol#L86

Tools Used

Foundry

Recommended Mitigation Steps

To mitigate this, the Ether should be sent using a call instead. And adding a Reetransy guard (even though I can't see any reentrance vulnerability, it can be good hygiene to mitigate reentrance when later updating the contracts).