Signature Validation Bypass in 'permit' Function of MarketERC20.sol

[code423n4]

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/MarketERC20.sol#L251

Vulnerability details

Description

The 'MarketERC20.sol' contract contains a critical vulnerability in the 'permit' function, where insufficient signature validation allows for bypassing the authentication process. This loophole enables attackers to manipulate the function by providing an invalid signature, causing the 'ECDSA.recover' method in line 276 to return 'address(0)' (zero address). If the attacker sets 'owner' as 'address(0)' in the input, they gain unauthorized access to all Zombie tokens held by 'address(0)', essentially taking ownership of these tokens or borrowing them without any restrictions.

The 'permit' function is designed to provide an owner with the ability to approve third-party addresses to spend tokens on their behalf. However, due to the flawed signature validation process, attackers can exploit this function to impersonate the zero address ('address(0)'), giving them control over Zombie tokens meant to be locked or reserved for specific purposes.

The impact of this vulnerability is severe, as it allows attackers to gain control over valuable assets and disrupt the intended financial operations within the 'MarketERC20' contract. It jeopardizes the security of the platform and undermines the trust of users.

Proof of concept and Impact

1) Exploiting the Vulnerability: Call the 'permit' function with an invalid signature that leads to the 'ECDSA.recover' method returning 'address(0)'. Set 'owner' as 'address(0)' in the input parameters. As a result, the attacker gains unauthorized access to Zombie tokens held by 'address(0)'. 2) Impact: Unauthorized control over Zombie tokens meant for specific purposes. Unauthorized borrowing or transfers of Zombie tokens.

Mitigation

Require(owner!=signer); after taking the signer value from recover As suggested in the ERC-2612 standard: https://eips.ethereum.org/EIPS/eip-2612

Assessed type

Invalid Validation

[c4-pre-sort]

minhquanym marked the issue as low quality report

[minhquanym]

Invalid

[c4-judge]

dmvt marked the issue as unsatisfactory: Invalid