Escher contest - 0xhacksmithh's results

Lines of code

https://github.com/code-423n4/2022-12-escher/blob/main/src/minters/LPDA.sol#L105

Vulnerability details

Impact

User may lose his fund(eth) as contract file(LPDA.sol) trying to send remaining eth via transfer()

Proof of Concept

After buying Buyer can withdraw his remaining fund via refund function, but refund function using transfer() for refunding eth, where transfer() and send() functions forward a fixed amount of 2300 gas. As well here return value of transfer also not checked, if transfer of eth failed, user balance on state variable get updated and eth remain stucked in this contract(LPDA.sol) for whole time.

Historically, it has often been recommended to use these functions for value transfers to guard against reentrancy attacks. However, the gas cost of EVM instructions may change significantly during hard forks which may break already deployed contract systems that make fixed assumptions about gas costs. For example. EIP 1884 broke several existing smart contracts due to a cost increase of the SLOAD instruction.

function refund() public {
        Receipt memory r = receipts[msg.sender];
        uint80 price = uint80(getPrice()) * r.amount;
        uint80 owed = r.balance - price;
        require(owed > 0, "NOTHING TO REFUND");
        receipts[msg.sender].balance = price;
        payable(msg.sender).transfer(owed); 

Tools Used

Manual review

Recommended Mitigation Steps

call() should be used instead of transfer() on an address payable