Addressing the veCHESS Crosschain Griefing Vulnerability

Summary

Recently, a medium-severity vulnerability was identified in Tranchess’s smart contract, specifically within the veChessCrossChain function of the VotingEscrowV4 contract. This issue allowed attackers to exploit the contract's mechanics, resulting in a griefing attack where despite no profits for the attacker, victims were unable to release their lock on the current chain after cross-chain transactions. We have thoroughly investigated this issue and have implemented measures to ensure the security of our protocol.

Description of the Issue

The vulnerability arose from the combination of two mechanisms in the VotingEscrowV4 contract:

1. Resetting Unlock Time: In the veChessCrossChain function, if a user's lockedBalance is reduced to 0, the unlockTime is reset to 0. This allows the user to lock any amount for any duration on this chain again.
2. Increasing Lock Amount: The increaseAmount function allows any user to increase the lockAmount for a target user, provided the current lock has not expired. There is no restriction to limit this function only to the msg.sender.

Attackers could exploit these mechanisms by front-running a user’s transaction in the mempool, executing increaseAmount to add a minimal amount (e.g., 1 wei) to the user's lockedBalance just before the user transfers all their locked balance through veChessCrossChain to another chain. As a result, the user would be left with a minimal lock amount that must wait to be unlocked, preventing the user from initiating a new lock with a shorter duration.

Impact

This vulnerability allowed attackers to prevent victims from releasing their lock on the current chain after cross-chain transactions, effectively restricting the victims’ ability to re-lock their assets for a shorter duration than the current lock. The attack could be executed at a very low cost, posing a griefing risk to protocol users.

Remediation

Upon receiving the ImmuneFi report, our team promptly reviewed the findings and confirmed the existence of the issue. We explored several approaches to address the vulnerability and decided to implement a solution that maintains the existing interface while ensuring the security of the protocol.

We are updating the VotingEscrowV4 contract to include a check that ensures the newAmount resulting from a cross-chain lock is non-zero. This measure will prevent attackers from exploiting the mechanism to leave users with a minimal lock amount.