31141 - [SC - Critical] Permanent freezing of unclaimed yield of reward...
Permanent freezing of unclaimed yield of reward tokens in Bribe contract when attackers maliciously exploit voter.poke()
Submitted on May 13th 2024 at 10:11:55 UTC by @perseverance for Boost | Alchemix
Report ID: #31141
Report type: Smart Contract
Report severity: Critical
Target: https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol
Impacts:
Permanent freezing of unclaimed yield
Permanent freezing of unclaimed royalties
Description
Description
Brief/Intro
Bribe contracts allow bribing users with voting power to vote for a specific gauge. The contract allows bribed users to claim their bribes.
when the function notifyRewardAmount() is called, the reward token is sent from the msg.sender to bribe contract and kept in this contract as reward.
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol#L112
Holders of VeAlcx tokens after voting in Voter contract will earn some reward and can claim reward by calling function claimBribes in voter contract.
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Voter.sol#L332-L338
Reward is calculated as follow:
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol#L283C5-L300C6
The earned() internal function is used to calculate the reward for a user.
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol#L265-L278
The _priorSupply is taken from votingCheckpoints[].votes. This votes are updated whenever the deposit function into Bribe is called when user vote via Voter contract.
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol#L306C8-L316C6
_writeVotingCheckpoint() is called.
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol#L362-L372
The vulnerability
Vulnerability Details
With that basic understanding, I will explain the Vulnerability now.
The vulnerability is that when user deposit() by calling vote() function via Voter contract, then the _writeVotingCheckpoint() is called. Then the votingCheckpoints[].votes is updated to be the totalVoting. In the function deposit, the totalVoting is increased. But in function withdraw() the totalVoting is not decreasing.
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol#L309
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/Bribe.sol#L319-L329
So now in the Voter contract, the function poke() allows the owner of tokenId to call in the same EPOCH. If this happen, then the vote of user is first withdrawned and then deposit again. The balanceOf and totalSuppy is accounting correctly, but the totalVoting will be increased because in withdraw() function, it was not updated.
So if a user call poke() in the same EPOCH, he will cause the totalVoting to be wrong. The attacker can maliciously call poke() several times to maliciously inflate the totalVoting.
When the totalVoting is inflated, each user will receive less reward intended by the system. So total earned will be less then the total reward. The reward left in the contract will be frozen as there is no way to take this reward out of the contract.
To easier for understanding, I will explain this with a scenario.
Step 1: 3 users: Alice, Bob and the attacker create locks with 1e18 BPT token
Step 2: The bribe contract receive some reward, suppose 100_000e18 BAL
Step 3: Each user will vote
Step 4: Fast forward 1 EPOCH and each user will be able to claim 1/3 of 100_000e18 BAL token as reward. If all users claim then the left token in the contract will be nearly zero.
So each user will get: 33333.33333333e18 that is 1/3 of the reward. This is expected amount
Log:
But if the user call poke() in the same EPOCH as in the step 3, then the totalVoting will be inflated.
I demonstrated this in the test case testBribeClaimingPoke_Hacked_2()
The log shows:
And then in step 4, the total of rewards claimed by all users will be less than the total reward. There will be tokens left in the contract. Bal balance of Bribe contract: 25000000000000000000000
Now the attacker can also exploit this vulnerablity to cause "Permanent freezing of unclaimed yield" or 'Permanent freezing of unclaimed royalties" by maliciously call poke() many times to inflate totalVoting. The left amount of reward will be stuck in this contract. There is no way to get it out so it is Permanent freezing of unclaimed yield. s
I demonstrated this in the test case: testBribeClaimingPoke_Hacked()
So the totalVoting will be inflated more and the left token will be more. In this POC, the Bal balance left in the Bribe contract 50000000000000000000002 that is 1/2 of the reward amount.
Log:
Impacts
About the severity assessment
The impact of this vulnerability is: This bug will result in "Permanent freezing of unclaimed yield" or 'Permanent freezing of unclaimed royalties" because the reward token will be left in the Bribe contract and cannot be taken out, so it is permanently frozen in this contract.
This bug can happen with normal users when the call the poke() in the same EPOCH as vote().
Or this bug can be exploited by attacker to cause this impact.
This bug severity: High Category: Permanent freezing of unclaimed yield or Permanent freezing of unclaimed royalties
Capital for the attack: Gas to execute the transactions. Some amount of BPT to invest to lock to get the VeAlcx tokens.
Easy to exploit and easy to be automated.
Proof of concept
Proof of concept
I created 3 test cases to demonstrate the 3 scenarios for attack and a normal scenario to clearly see the attack.
testBribeClaimingPoke_Hacked
I demonstrated this attack in the test case:
Step 1: 3 users: Alice, Bob and the attacker create locks with 1e18 BPT token
Step 2: The bribe contract receive some reward, suppose 100_000e18 BAL
Step 3: Each user will vote
Step 3.1: Attacker call poke() repeatedly to inflate the totalVoting
Step 4: Fast forward 1 EPOCH and each user will be able to claim 1/3 of 100_000e18 BAL token as reward. If all users claim then the left token in the contract will be nearly zero.
The full log of this test case:
testBribeClaimingPoke_Hacked_2()
I also created the test case for the case that a normal user call poke() in this POC:
The full log:
testBribeClaimingPoke_Normal()
I also created the test case for a normal scenario
The log:
The left token in the contract in this scenario is 1 token, that is just dust.
The full test cases:
To run the test, just copy the test code in the file:
https://github.com/alchemix-finance/alchemix-v2-dao/blob/main/src/test/Voting.t.sol
Then run the command:
Full Log: https://drive.google.com/file/d/1zU9SNWECqE7S_eZRMjFOg1Ha-CNvyxHv/view?usp=sharing
Full log with debug information: https://drive.google.com/file/d/1cBNi1a0Um1G0OTCny7KvnpUbXq1FEs1-/view?usp=sharing
Last updated
Was this helpful?