065.md

Precise Scarlet Millipede

Medium

Possible DOS (Deny Of Service) if _refundAddress is a contract that cannot receive eth

Summary

The sendMessage()::L1CrossDomainMessenger.sol function will fail if _refundAddress is a contract that cannot receive ether.

https://github.com/sherlock-audit/2024-08-morphl2/blob/main/morph/contracts/contracts/l1/L1CrossDomainMessenger.sol#L112-L120

Root Cause

In L1CrossDomainMessenger.sol : https://github.com/sherlock-audit/2024-08-morphl2/blob/main/morph/contracts/contracts/l1/L1CrossDomainMessenger.sol#L359-L363

uint256 _refund = msg.value - _fee - _value;
            if (_refund > 0) {
                (bool _success, ) = _refundAddress.call{value: _refund}(""); // <-- can cause a DOS (Deny Of Service)
                require(_success, "Failed to refund the fee");
            }

These lines of code can cause a DOS : Deny Of Service. If the _refundAddress is a contract that can not receive ether, meaning neither a receive() payable nor fallback() payable function is implemented, the transaction will automatically fail.

External pre-conditions

1. _refundAddress is a contract
2. _refundAddress does not implement a receive() payable function nor a fallback() payable function.
3. There is a _refund amount to refund

Attack Path

1. _refundAddress is a contract that can not receive ETH
2. there is a surplus of eth sent by the user, meaning there is a _refund amount to send to the _refundAddress
3. the contract tries to send this _refund amount of native ETH to the _refundAddress
4. the transaction fails

Impact

Deny Of Service, the transaction will fail every time.

Mitigation

One possibility would be to convert the _refund amount to wrap ether (WETH), and then send it to the _refundAddress. Wether _refundAddress is a contract able to receive ether or not, the transaction will always go through.

Or, check if the _refundAddress is a contract, if it's not => refund with native ether, if it is => refund with Wrap Ether (WETH).