SushiSwap — Voting Vulnerability of SUSHI Token (and Its Forks)

Originally published in Valix Consulting’s Medium.

This report exposes our findings toward the design flaws under the inherent voting mechanism of the SUSHI token, which can also affect every forked project to be attacked. We also give solutions to remediating its issues in the end.

Table of Contents

• TLDR

• Overview of SUSHI Token’s Voting Functionality

• Voting Amplification Attack

• Voting Displacement Attack

• Redelegation Failure

• Recommended Remediation

• Awareness of Design Flaws

• Summary

.    .    .

TLDR

The voting functionality of the SUSHI token has some flaws in its design, leading to potential attacks and issues, including voting amplification attack, voting displacement attack, and redelegation failure issue.

The attacks and issues can affect every DeFi project forked from the SushiSwap if the voting functionality in question is switched on regrettably.

.    .    .

Overview of SUSHI Token’s Voting Functionality

SUSHI token was designed to be a governance token. The token’s underlying feature is voting functionality. The SUSHI token holders can vote on proposals to change the platform’s parameters, resulting in the decentralized governance of the platform by the community.

The SUSHI token holders can even delegate their votes, representing by the holding SUSHIs, to a representative to gather voting power from the ones who have the same expectancy on the way to improve the platform, as portrayed in Figure 1.

Unfortunately, some design flaws in the voting mechanism have inherently resided since the first block of the token deployment. The following sections explain the potential attacks and issues if the SUSHI token’s voting functionality is turned on.

The potential attacks and issues include:

1. Voting Amplification Attack

2. Voting Displacement Attack

3. Redelegation Failure

.    .    .

Voting Amplification Attack

The first potential attack is voting amplification. This attack enables attackers to massively amplify their votes on any desired representative or proposals with a minimal attack cost.

Figure 2 shows the _moveDelegates function that is the root cause of the attack. This function is executed during the voting delegation process to move the delegator’s votes to the representative. In other words, the amount of the votes (represented by the SUSHI tokens) from a delegator will be increased to the representative (line no’s. 210–213).

Although the _moveDelegates function can move the delegator’s votes to the targeting representative correctly, the function does not lock up the delegated SUSHI tokens inside the contract.

This design flaw opens the room for a double-spending attack in which attackers can create Sybil accounts leading to the voting amplification.

For the sake of better understanding, let’s consider the voting amplification attack scenario in Figure 3 above.

1. Attacker #1 initially has 100 SUSHIs and delegates his vote to Bob

2. Bob now collects 100 votes

3. Attacker #1 transfers his 100 SUSHIs to Attacker #2

4. Attacker #2 delegates the obtained 100 SUSHIs to Bob

5. Bob’s collected votes have been amplified to 200

As you may see, the attackers can easily amplify Bob’s votes by performing Steps 3 and 4 repeatedly.

.    .    .

Voting Displacement Attack

The second potential attack is voting displacement. This attack allows attackers to take out other voters' votes.

Figure 4 shows the _delegate and _moveDelegates functions that are the root cause of the attack. During the redelegation process, the _delegate function would be executed. This function gets the delegator’s current representative (line no. 189). Then, the function reads the delegator’s current SUSHI balance (line no. 190). Next, the function changes the representative to the new one (line no. 191).

Interestingly, the delegator’s SUSHI balance (from line no. 190) is passed into the _moveDelegates function (line no. 195) and becomes the function parameter, amount.

In the _moveDelegates function, the old representative’s votes are decreased by the variable amount (line no. 204). The exact amount is also increased to the new representative’s votes (line no. 212). In other words, the votes will be moved from the old to the new representative.

Since the amount of the moved votes is determined by the delegator’s current SUSHI balance, not the previously delegated SUSHIs, the attackers can manipulate the incorrect number of the votes movement.

To conclude, the delegator’s SUSHI balance (line no. 190) is the root cause of the attack.

To elaborate on the voting displacement attack, let’s consider the scenario illustrated in Figure 5.

1. Alice, Charles, and Dan delegate 100, 50, and 300 SUSHIs respectively to Bob

2. Bob collects 450 votes

3. Attacker #1 initially has 1 SUSHI and delegates his vote to Bob

4. Bob collects 451 votes for now

5. Attacker #2 transfers his 450 SUSHIs to Attacker #1

6. Attacker #1 now has 451 SUSHIs in his wallet

7. Attacker #1 re-delegates his vote to Attacker #2

8. Bob’s collected votes are improperly removed by 451 (i.e., the current SUSHI balance of Attacker #1) and finally become 0

9. Attacker #2 eventually receives the manipulated 451 votes

As you can see, the 450 votes (delegated by Alice, Charles, and Dan) to Bob are improperly removed at Step 8 due to the design flaw explained earlier. Hence, the attackers can use this voting displacement attack to dismiss the votes of other voters easily.

.    .    .

Redelegation Failure

Another issue of the SUSHI token is redelegation failure. This issue causes a transaction revert during the redelegation process, which can affect every regular voter.

Figure 6 points out the root cause of the issue; the _delegate and _moveDelegates functions. As described earlier, the _moveDelegates function will move a certain amount of votes from the old (line no’s. 202–205) to the new representative (line no’s. 210–213). The votes movement amount is determined by the delegator’s current SUSHI balance (line no. 190) in the _delegate function.

During the redelegation process, the transaction would be reverted in line no. 204 if the delegator has more SUSHI balance than the votes previously recorded.

More specifically, the _moveDelegates function would attempt to deduct the surpassing number from the exact number recorded, causing an integer underflow error. Thus, the sub function of the SafeMath library would revert the transaction.

The redelegation failure scenario can be depicted using Figure 7.

1. Alice initially has 100 SUSHIs and delegates her vote to Bob

2. Bob obtains 100 votes now

3. Charles transfers his 50 SUSHIs to Alice

4. Alice now has 150 SUSHIs in her wallet

5. Alice tries to re-delegate her votes to another representative, Dan

6. The redelegation transaction is reverted due to the integer underflow error

Three possible actions can cause Alice’s transaction to revert.

1. Alice receives additional SUSHIs from the token transfer (from others)

2. Alice receives additional SUSHIs from the token buying

3. Alice receives additional SUSHIs from the yield farming

This issue can affect both the voting redelegation and voting withdrawal transactions invoked by a regular voter.

.    .    .

Recommended Remediation

We recommend two possible solutions to remediate the issues.

1. The first solution is improving the SushiToken contract to lock away the delegated SUSHI tokens inside until the voting or delegating period is complete. The SushiToken contract also has to record the number of votes of each delegator correctly so that the contract can check and move each delegator’s votes precisely when re-delegating.
   
   

2. Another solution is implementing another voting contract and using SUSHI tokens as the contract’s voting tokens. The voting contract also needs to lock up and record the delegated SUSHI tokens correctly nonetheless.

.    .    .

Awareness of Design Flaws

The SushiSwap team has already learned the living of the design flaws. As you can see in Figure 8, they recommend no using the voting functionality in production. And, the team opts to use an off-chain gasless voting platform named Snapshot for its community voting instead.

Since the codebase of the SUSHI token is used by tons of DeFi projects nowadays, the Valix Consulting team would like to raise awareness about its living issues to the DeFi users and platform developers to secure the DeFi ecosystem.

.    .    .

Summary

SushiToken contract is one of the most adopted smart contract codebases being used by tons of DeFi projects. The contract, nevertheless, has some flaws in its design affecting its voting functionality.

In this report, we expose our findings regarding the voting issues. We also recommend solutions to remediate the issues.

.    .    .

Author Details

Phuwanai Thummavet (serial-coder), Lead Blockchain Security Auditor and Consultant | Blockchain Architect and Developer.

See the author’s profile.

.    .    .

About Valix Consulting

Valix Consulting is a blockchain and smart contract security firm offering a wide range of cybersecurity consulting services. Our specialists, combined with technical expertise with industry knowledge and support staff, strive to deliver consistently superior quality services.

For any business inquiries, please get in touch with us via Twitter, Facebook, or info@valix.io.

.    .    .

Originally published in Valix Consulting’s Medium.