jo13 - Gas Manipulation by Malicious Winners in claimPrizes Function

[sherlock-admin4]

jo13

medium

Gas Manipulation by Malicious Winners in claimPrizes Function

Summary

A malicious winner can exploit the claimPrizes function in the Claimer contract by reverting the transaction through returning a huge data chunk. This manipulation can cause the transaction to run out of gas, preventing legitimate claims and allowing the malicious user to claim prizes without computing winners.

Vulnerability Detail

• The Claimer contract allows users to claim prizes on behalf of others by calling the claimPrizes function.
• A malicious winner can exploit this function by returning a huge data chunk when called, causing the transaction's gas to be too high and revert.
• Although the function catches the revert, the remaining gas (63/64 of the original gas) is likely insufficient for the rest of the claims.
• The malicious winner can then replay the transaction to claim the fees from the first claimer's computation without needing to compute the winners themselves.

Impact

• Legitimate claimers may lose gas fees due to transaction reverts caused by malicious winners.
• Malicious winners can exploit this to claim prizes without computing winners, undermining the fairness of the prize distribution.

Recommendation

• Implement a gas limit check to ensure that sufficient gas remains for the rest of the claims after catching a revert.
• Consider adding a mechanism to penalize or blacklist addresses that attempt to exploit this vulnerability.

[InfectedIsm]

Escalate

issue #110 doesn't talk about gas bomb through return data, and shouldn't be a duplicate of this issue. If there's an issue that could be seen as similar, it would be #73, as in that one the attacker steal the reward that was attributed to the original claimer

[sherlock-admin3]

Escalate

issue #110 doesn't talk about gas bomb through return data, and shouldn't be a duplicate of this issue. If there's an issue that could be seen as similar, it would be #73, as in that one the attacker steal the reward that was attributed to the original claimer

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[nevillehuang]

Escalation should be rejected, watson didn't pay attention to the correct duplication. #110 is already duplicated to #73

[WangSecurity]

Agree with the Lead Judge, planning to reject the escalation and leave the issue as it is.

[WangSecurity]

Result: Medium Has duplicates

[sherlock-admin4]

Escalations have been resolved successfully!

Escalation status:

• InfectedIsm: rejected

[sherlock-admin2]

The protocol team fixed this issue in the following PRs/commits: https://github.com/GenerationSoftware/pt-v5-vault/pull/115

[10xhash]

Fixed Now ExcessivelySafeCall is used restricting the return/revert data copying to 128 bytes

[sherlock-admin2]

The Lead Senior Watson signed off on the fix.