code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2023-07-moonwell/blob/fced18035107a345c31c9a9497d0da09105df4df/src/core/MErc20Delegator.sol#L97

Vulnerability details

Impact

According to the MTokenInterfaces, the mintWithPermit function should be compliant with EIP-2612.

Proof of Concept

It is only currently passing these params to the function:

    function mintWithPermit(uint mintAmount, uint deadline, uint8 v, bytes32 r, bytes32 s) virtual external returns (uint);

It is expected to pass these params:

function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external

If these conditions are not met, there will be a revert.

keccak256(abi.encodePacked(
   hex"1901",
   DOMAIN_SEPARATOR,
   keccak256(abi.encode(
            keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)"),
            owner,
            spender,
            value,
            nonce,
            deadline))
))

Tools Used

Manual Review

Recommended Mitigation Steps

Please follow the instructions in the EIP-2612 standard below regarding the permit implementation.

https://eips.ethereum.org/EIPS/eip-2612

Assessed type

Other

0xSorryNotSorry commented 1 year ago

It's the intended mechanism as per the NATSPEC

* @notice Supply assets but without a 2-step approval process, EIP-2612

c4-pre-sort commented 1 year ago

0xSorryNotSorry marked the issue as low quality report

alcueca commented 1 year ago

It is not intended that MErc20Delegator implements EIP-2612, but that it accepts permits for a EIP-2612 token. Invalid finding.

c4-judge commented 1 year ago

alcueca marked the issue as unsatisfactory: Invalid

code-423n4 / 2023-07-moonwell-findings

[ M ] MErc20Delegator.sol Not compliant with EIP-2612 #295