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

Delegatee can prevent his delegators to undelegate and withdraw votes #245

Closed
code423n4 opened this issue Aug 10, 2023 · 11 comments
Closed
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-182 satisfactory satisfies C4 submission criteria; eligible for awards upgraded by judge Original issue severity upgraded from QA/Gas by judge

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2023-08-verwa/blob/main/src/VotingEscrow.sol#L331
https://github.com/code-423n4/2023-08-verwa/blob/main/src/VotingEscrow.sol#L383
https://github.com/code-423n4/2023-08-verwa/blob/main/src/VotingEscrow.sol#L384

Vulnerability details

Impact

Users in the VotingEscrow contract can delegate their voting balance to other accounts with a non-zero stake. To undelegate his votes back the user has to satisfy following conditions

  • has non-expired lock
  • user from whom he undelegates has a shorter lock.
    This leads to a situation where a user with a delegatee would be unable to undelegate and withdraw his CANTO tokens without increasing his own lock. In the edge case malicious delegatee can prevent delegator from undelegating his votes.

Alice has a lock, she delegates to Bob, later she wants to undelegate her votes, she extends her lock (to satisfy to.end >= from.end). Bob frontruns her transaction and increases his lock first, thus his lock time is greater than Alice's. As a result Alice needs to increase lock again to undelegate and Bob can repeat a frontrun again.

Proof of Concept

test case for VotingEscrow.t.sol

    function testUndelegateFail() public {
        // Lock with a duration 5 year should be created with delegated set to msg.sender
        vm.prank(user1);
        ve.createLock{value: 100 ether}(100 ether);
        assertEq(ve.lockEnd(user1), _floorToWeek(block.timestamp + ve.LOCKTIME()));
        (, , , address delegatee) = ve.locked(user1);
        assertEq(delegatee, user1);

        vm.prank(user2);
        ve.createLock{value: 0.1 ether}(0.1 ether);

        vm.prank(user1);
        ve.delegate(user2);

        vm.warp(block.timestamp + WEEK);
        // frontrun user1 and extend lock
        vm.prank(user2);
        ve.increaseAmount{value: 1}(1);
        // user1 fails to undelegate
        vm.prank(user1);
        vm.expectRevert("Only delegate to longer lock");
        ve.delegate(user1);
    }

Tools Used

Foundry

Recommended Mitigation Steps

Implement a function that will allow delegator to forcefully undelegate his votes if needed.

Assessed type

DoS

@code423n4 code423n4 added 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 labels Aug 10, 2023
code423n4 added a commit that referenced this issue Aug 10, 2023
@c4-pre-sort
Copy link

141345 marked the issue as duplicate of #116

@c4-pre-sort
Copy link

141345 marked the issue as duplicate of #82

@c4-judge c4-judge added 3 (High Risk) Assets can be stolen/lost/compromised directly upgraded by judge Original issue severity upgraded from QA/Gas by judge and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Aug 24, 2023
@c4-judge
Copy link

alcueca changed the severity to 3 (High Risk)

@c4-judge c4-judge added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue and removed 3 (High Risk) Assets can be stolen/lost/compromised directly upgraded by judge Original issue severity upgraded from QA/Gas by judge labels Aug 24, 2023
@c4-judge
Copy link

alcueca changed the severity to 2 (Med Risk)

@c4-judge
Copy link

alcueca marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Aug 24, 2023
@c4-pre-sort
Copy link

141345 marked the issue as not a duplicate

@c4-pre-sort
Copy link

141345 marked the issue as duplicate of #375

@c4-judge c4-judge reopened this Aug 24, 2023
@c4-judge c4-judge added primary issue Highest quality submission among a set of duplicates selected for report This submission will be included/highlighted in the audit report labels Aug 24, 2023
@c4-judge
Copy link

alcueca marked the issue as selected for report

@c4-judge
Copy link

alcueca marked the issue as duplicate of #182

@c4-judge c4-judge added duplicate-182 and removed primary issue Highest quality submission among a set of duplicates labels Aug 29, 2023
@c4-judge
Copy link

alcueca marked the issue as not selected for report

@c4-judge c4-judge removed the selected for report This submission will be included/highlighted in the audit report label Aug 29, 2023
@c4-judge
Copy link

alcueca changed the severity to 3 (High Risk)

@c4-judge c4-judge added 3 (High Risk) Assets can be stolen/lost/compromised directly upgraded by judge Original issue severity upgraded from QA/Gas by judge and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue labels Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-182 satisfactory satisfies C4 submission criteria; eligible for awards upgraded by judge Original issue severity upgraded from QA/Gas by judge
Projects
None yet
Development

No branches or pull requests

3 participants