The SignerValidator contract lacks sufficient checks to prevent an authorized signer from signing multiple claims for the same action and incentive, potentially allowing users to claim rewards multiple times for a single action. This is because the validation logic only checks if a particular incentive ID has been used for a given hash, but it does not account for cases where an authorized signer issues multiple signatures with different incentiveData for the same action.
Impact
The most significant impact of this vulnerability is the potential for duplicate incentive claims. This could lead to:
Depletion of Incentive Funds: Authorized signers could collude with users to drain the boost's budget by repeatedly claiming rewards for the same action.
Unfair Advantage: Some users could receive multiple rewards for a single action, creating an uneven playing field for other participants.
Scenario
Consider a boost where users earn a reward for performing an action, like making a purchase. An authorized signer, perhaps compromised or acting maliciously, could provide a user with multiple signatures containing different incentiveData, even though the user only performed the action once. The SignerValidator contract, as it stands, would approve these duplicate claims.
Fix
To remedy this, modify the validate function in SignerValidator to include the incentiveData in the hash used for tracking claimed incentives.
function hashSignerData(
uint256 boostId,
uint8 incentiveQuantity,
address claimant,
bytes memory incentiveData
) public view returns (bytes32 hashedSignerData) {
return
_hashTypedData(
keccak256(
abi.encode(
_SIGNER_VALIDATOR_TYPEHASH,
boostId,
incentiveQuantity,
claimant,
keccak256(incentiveData) // Include incentiveData in the hash
)
)
);
}
By including incentiveData in the hash, each unique claim, even for the same action, would generate a distinct hash. The setOrThrow function would then accurately track and prevent duplicate claims.
0xloophole
Medium
Incorrect Validation in SignerValidator
Details
The SignerValidator contract lacks sufficient checks to prevent an authorized signer from signing multiple claims for the same action and incentive, potentially allowing users to claim rewards multiple times for a single action. This is because the validation logic only checks if a particular incentive ID has been used for a given hash, but it does not account for cases where an authorized signer issues multiple signatures with different incentiveData for the same action.
Impact
The most significant impact of this vulnerability is the potential for duplicate incentive claims. This could lead to:
Depletion of Incentive Funds: Authorized signers could collude with users to drain the boost's budget by repeatedly claiming rewards for the same action.
Unfair Advantage: Some users could receive multiple rewards for a single action, creating an uneven playing field for other participants.
Scenario
Consider a boost where users earn a reward for performing an action, like making a purchase. An authorized signer, perhaps compromised or acting maliciously, could provide a user with multiple signatures containing different incentiveData, even though the user only performed the action once. The SignerValidator contract, as it stands, would approve these duplicate claims.
Fix
To remedy this, modify the validate function in SignerValidator to include the incentiveData in the hash used for tracking claimed incentives.
Here's how the modified hashSignerData function might look: https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/main/boost-protocol/packages/evm/contracts/validators/SignerValidator.sol#L93
By including incentiveData in the hash, each unique claim, even for the same action, would generate a distinct hash. The setOrThrow function would then accurately track and prevent duplicate claims.