Summary

The code appears to be an Escrow contract for handling transactions between a buyer, seller, and optional arbiter. It allows the buyer to create an escrow, deposit funds, and confirm receipt of services. In case of a dispute, the arbiter can resolve it and allocate funds accordingly. The code uses OpenZeppelin libraries for safe token transfers and reentrancy protection.

Vulnerability Details

Front-running Potential: The constructor of the Escrow contract is publicly accessible, and the tokenContract and buyer addresses are validated. However, the contract allows any address to deploy an escrow by sending funds to the contract address via create2. This could lead to a front-running attack, where malicious actors can deploy an escrow with incorrect details before the actual buyer can, resulting in disputes or unwanted escrows.

Denial-of-Service Potential: The contract allows any ERC20 token to be used as the payment token. If a malicious token with reentrant behavior or callbacks is used, it could lead to potential reentrancy attacks and denial of service (DOS) vulnerabilities during the dispute resolution process.

Arbiter Fee Limitation: The contract has a limitation where if the arbiterFee is set to a value close to or higher than the price of the escrow, it can lead to situations where the seller may choose not to perform the service, forcing the buyer to initiate a dispute and lose a significant portion of their funds to the arbiter.

Token Transfer Order: The contract resolves a dispute by first transferring the buyer's award and arbiter fee and then the remaining token balance to the seller. However, if the contract's token balance changes between transfers, it could result in an undesired distribution of funds.

Impact

The identified vulnerabilities could have serious consequences on the security and fairness of the escrow contract. Front-running attacks can disrupt the escrow creation process, and the use of malicious tokens can lead to reentrancy vulnerabilities and potential DOS attacks. Additionally, the limitation on the arbiter fee and token transfer order could result in undesired fund distribution and disputes.

Tools Used

Manual work and documentations

Recommendations

Access Control: Implement access control checks in the constructor or during escrow creation to ensure that only the intended buyer can deploy a new escrow.

Token Selection: Consider implementing a whitelist of trusted tokens or using only well-audited tokens for escrow payments to prevent potential reentrancy and DOS attacks.

Arbiter Fee Limits: Consider setting reasonable limits on the arbiter fee to ensure that the seller receives a fair payment and incentivize both parties to perform their obligations.

Atomic Token Transfer: Use an atomic token transfer method to ensure that the token balance doesn't change between transfers and avoid undesired fund distributions.

Testing and Auditing: Thoroughly test and audit the contract, including the interaction with different token contracts, to identify and mitigate any potential security risks.