Permit2 doesn't allow passing from != msg.sender

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-08-superposition/blob/main/pkg/seawater/src/wasm_erc20.rs#L188-L245

Vulnerability details

Impact

All the permit operations will be disabled for users who have valid signatures from the token owners due to msg.sender being used instead of from in wasm_erc20::take_permit2. As a result approved users won’t be able to manage positions that they have been approved to.

Proof of Concept

Positions in Seawater are represented by ERC721 contracts with approval mechanism, that means approved users can manage positions on behalf of their owners. There are also SeawaterAMM::incrPositionPermit25468326E and swapIn, swapOut with Permit.

However operators with valid Permit signatures won’t be able to manage any positions because take_permit2 always uses msg.sender as from:

wasm_erc20.rs

pub fn encode_permit2(
    token: Address,
    max_amount: U256,
    nonce: U256,
    deadline: U256,
    to: Address,
    transfer_amount: U256,
    from: Address,
    sig: &[u8],
) -> Vec<u8> {

pub fn take_permit2(
    token: Address,
    transfer_amount: U256,
    details: Permit2Args,
) -> Result<(), Error> {
    let data = encode_permit2(
        token,
        details.max_amount,
        details.nonce,
        details.deadline,
        contract::address(),
        transfer_amount,
        msg::sender(),
        details.sig,
    );

    match RawCall::new().call(PERMIT2_ADDR, &data) {
        Ok(_) => Ok(()),
        Err(v) => Err(Error::Erc20Revert(v)),
    }
}

As a result only the owner who has permitted himself can use that functionality and can’t grant anyone else who he trusts to perform operations for his position or assets.

However the purpose of permit is to allow someone to sign approve signature, so that this signature can be used by another contract to call some function on behalf of signer.

The exact same issue has been found in PoolTogether - code-423n4/2023-07-pooltogether-findings#113

Tools Used

Manual Review

Recommended Mitigation Steps

Allow passing from address who is different from the msg.sender.

Assessed type

ERC20

[alex-ppg]

The submission details that Permit2 operations are presently solely supported when the caller themselves have signed the permit payload.

I am unsure why this would be considered a vulnerability as the user may wish to avoid executing two transactions (one to approve and one to interact) which is the entire premise the permit system was built on in the first place.

Additional security measures need to be set in place if an arbitrary from argument can be specified to avoid permit payloads of other users to be arbitrarily consumed. I am inclined to consider this a QA recommendation as an expansion of the features the system supports rather than an actual HM vulnerability or missing feature.

[c4-judge]

alex-ppg changed the severity to QA (Quality Assurance)

[c4-judge]

alex-ppg marked the issue as grade-c

[c4-judge]

alex-ppg marked the issue as grade-b