Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Penalty will be forced even when user wants to lock amount #49

Closed
code423n4 opened this issue May 15, 2022 · 4 comments
Closed

Penalty will be forced even when user wants to lock amount #49

code423n4 opened this issue May 15, 2022 · 4 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) duplicate This issue or pull request already exists resolved Finding has been patched by sponsor (sponsor pls link to PR containing fix) sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-05-aura/blob/main/contracts/AuraBalRewardPool.sol#L176

Vulnerability details

Impact

In case shutdown function had been called on AuraLocker, the lock function on AuraLocker will fail. This means Users will be forced to call getReward function with _lock as false which also means that 20% will be deducted from there reward as penalty even though it is not there fault.

Proof of Concept

  1. User calls the getReward function with _lock as true
  2. The call fails since shutdown is true in AuraLocker which makes the below require fail
require(!isShutdown, "shutdown"); 
  1. User can only get reward if _lock is kept as false but this cuts 20% penalty fees even though there is no fault from user side

Similar occurence

** Same issue also holds for claim function at https://github.com/code-423n4/2022-05-aura/blob/main/contracts/AuraMerkleDrop.sol#L114 & AuraVestedEscrow.sol#L61 **

Recommended Mitigation Steps

Ideally getReward function should be revised:

AuraLocker.sol

function getShutDownStatus() external returns(bool) {
        return shutdown;
    }

AuraBalRewardPool.sol#L176

function getReward(bool _lock) public updateReward(msg.sender) returns (bool) {
        uint256 reward = rewards[msg.sender];
        if (reward > 0) {
            rewards[msg.sender] = 0;
			
			// this will prevent the shutdown fees scenario
			if(shutdown){
			rewardToken.safeTransfer(msg.sender, reward);
			}
			
            else if (_lock) {
                auraLocker.lock(msg.sender, reward);
            } else {
                uint256 penalty = (reward * 2) / 10;
                pendingPenalty += penalty;
                rewardToken.safeTransfer(msg.sender, reward - penalty);
            }
            emit RewardPaid(msg.sender, reward, _lock);
        }
        return true;
    }
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels May 15, 2022
code423n4 added a commit that referenced this issue May 15, 2022
@0xMaharishi 0xMaharishi added invalid This doesn't seem right sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) labels May 25, 2022
@0xMaharishi
Copy link

Considering this only affects reward tokens, and would only be the case if a significant bug was found in the AuraLocker causing it to shut down.. this should be a 0 or 1 at most.. 3.. LOL

@0xMaharishi 0xMaharishi added the resolved Finding has been patched by sponsor (sponsor pls link to PR containing fix) label May 30, 2022
@dmvt
Copy link
Collaborator

dmvt commented Jun 20, 2022

I agree with sponsor that this is not a high severity issue, but it would cause loss of funds given external factors that are beyond the control of the user. Accordingly, medium makes sense here.

@dmvt dmvt closed this as completed Jun 20, 2022
@dmvt dmvt reopened this Jun 20, 2022
@dmvt dmvt added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value and removed 3 (High Risk) Assets can be stolen/lost/compromised directly invalid This doesn't seem right labels Jun 20, 2022
@IllIllI000
Copy link

this is the same as #179

@dmvt
Copy link
Collaborator

dmvt commented Jul 12, 2022

Duplicate of #179

@dmvt dmvt marked this as a duplicate of #179 Jul 12, 2022
@dmvt dmvt closed this as completed Jul 12, 2022
@JeeberC4 JeeberC4 added the duplicate This issue or pull request already exists label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) duplicate This issue or pull request already exists resolved Finding has been patched by sponsor (sponsor pls link to PR containing fix) sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons
Projects
None yet
Development

No branches or pull requests

5 participants