Paladin - Warden Pledges contest - 0xDjango's results

Lines of code

https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L387 https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L432

Vulnerability details

Impact

The pledge creator must send more rewards than necessary in order to extend their pledge end timestamp or increase the reward per vote. This is because the calculation to determine the amount of rewards to send uses the original pledgeParams.votesDifference set at the time of pledge creation instead of the current balance of the receiver.

Proof of Concept

Take the following example, illustrating the calculation of rewards to send using the original vote difference:

uint256 totalRewardAmount = (pledgeParams.rewardPerVote * pledgeParams.votesDifference * addedDuration) / UNIT;

• Creator creates pledge (receiver = creator).
• Current creator balance = 100.
• targetVotes = 500.
• Time passes and the creator accumulates more of their own VE tokens. Their un-boosted balance increases to 300.
• Creator attempts to extend their pledge.
• The function calculates the amount of rewards to send via the original vote difference (400) instead of the current vote difference (200).
• The creator must send double the rewards despite not needing to.

Tools Used

Manual review.

Recommended Mitigation Steps

Function calls to extend the pledge or increase the reward per vote must take the current vote difference instead of the original difference set at pledge creation.

Lines of code

https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L233-L237

Vulnerability details

Impact

The _pledge() function contains checks ensuring that the endTimestamp is not greater than the pledgeParams.endTimestamp and that endTimestamp is rounded to the week, but it does not check that endTimestamp is larger than some minimum pledge time. Currently, an "attacker" or griefer can pledge a large amount for a small amount of time. They can pledge for a length of time where the receiver may not even have enough time to submit a transaction to take advantage of the boost.

This most likely will not provide a large monetary incentive to the attacker, but the pledge creator's reward funds will be paid out for no reason.

Proof of Concept

• A malicious actor realizes that the week timestamp is approaching in 10 minutes.
• They pledge a large amount of points to the pledge creator with the endTimestamp equal to the upcoming week timestamp (10 minutes away).
• The receiver doesn't feasibly have enough time to act while the boost is active.
• The malicious actor receives some reward without providing any benefit to the receiver.

Tools Used

Recommended Mitigation Steps

Add a check for MIN_PLEDGE_TIME, a constant equal to a value that makes sense, e.g. 86400 (1 day).