Full Report
The SUSHI token is a governance token with voting power. The SUSHI holders can delegate their votes to other users to gang vote on proposals as well. This entity is known as the representative. The protocol had some design flaws in it. The function _moveDelegates is executed during the voting delegation process to give the votes to a representative. Although the voting power is moved to the representative, the delegator's tokens are NOT. So, they can transfer the tokens to another user who can now vote or delegate further these further. This is known as a sybil or double spend attack. The second vulnerability is a logic flaw in changing representatives. During the redelegation process, the previous delegates voting tokens are subtracted from and the new delegates tokens are added to. However, the previous delegate token amount subtracts with the current token amount instead of the previous. This means that we can subtract votes from a representative by simply delegating, buying SUSHI and changing representatives. The previous vulnerability can also cause a denial of service (DoS). A user may want to redelegate their funds to another. However, since the current SUSHI token count is used instead of the previous one, the arithmetic can underflow. Interestingly, these are known bugs by the SUSHI team. In the contract code, there is a comment saying to NOT use this token for security reasons. I'm sure when people assumed the code worked fine though. Why wouldn't they just patch the bugs then? So weird. Overall, impactful and simple logic bugs.
Analysis Summary
# Vulnerability: SushiSwap Voting Logic Flaws (Sybil & Denial of Service)
## CVE Details
- **CVE ID**: Not Assigned (Design flaw in specific smart contract implementation)
- **CVSS Score**: High (Estimated 7.5 - 8.2)
- **CWE**: CWE-841 (Improper Enforcement of Behavioral Workflow), CWE-682 (Incorrect Calculation)
## Affected Systems
- **Products**: SushiSwap (SUSHI) Token Contract and its derivatives.
- **Versions**: Original `SushiToken.sol` deployment and any fork inheriting the voting delegation logic.
- **Configurations**: DeFi protocols where the `voting functionality` is actively enabled for governance.
## Vulnerability Description
The SUSHI token includes a voting mechanism where holders can delegate voting power to a representative. Two primary logic flaws exist within the `_moveDelegates` function:
1. **Voting Amplification (Sybil Attack)**: The delegation process moves "votes" to a representative but does not lock the underlying tokens. An attacker can delegate votes to a representative, transfer the tokens to a new wallet, and delegate again. This allows an attacker to multiply their voting power indefinitely with the same capital.
2. **State Mismatch (Redelegation/DoS)**: When a user changes representatives (redelegation), the contract subtracts the user's *current* token balance from the *old* delegate’s tally.
* **Displacement Attack**: If a user delegating to "Representative A" buys more tokens before switching to "Representative B," Representative A loses more votes than they originally received from that user.
* **Denial of Service (Arithmetic Underflow)**: If the subtraction results in a value lower than zero (due to the delegate's total power being less than the user's new balance), the transaction reverts. This can block users from redelegating or moving funds.
## Exploitation
- **Status**: PoC available/Publicly documented.
- **Complexity**: Low.
- **Attack Vector**: Network (Smart Contract Interaction via Ethereum/EVM compatible chains).
## Impact
- **Confidentiality**: None.
- **Integrity**: High (Governance outcomes can be manipulated via amplified votes).
- **Availability**: High (Users can be locked in a specific delegation state due to arithmetic reverts).
## Remediation
### Patches
- The SUSHI team included comments in the source code warning against the use of these specific features for security reasons; however, many forks ignored this.
- Deployment of a revised token contract or a secondary "Voting Escrow" (ve-model) contract is required to properly track snapshots or lock tokens.
### Workarounds
- **Disable Governance**: Disable the native voting functions in favor of off-chain snapshotting (e.g., Snapshot.org) which calculates votes based on token balances at a specific block height.
- **Balance Checks**: Implement manual checks to ensure users cannot transfer tokens if they have active delegations.
## Detection
- **Indicators of compromise**: Unusual spikes in voting power for specific addresses; frequent transfers of tokens between addresses followed by delegation calls in the same or sequential blocks.
- **Detection methods and tools**: Static analysis of the `_moveDelegates` function in Solidity; monitoring for `MoveDelegates` events on-chain.
## References
- SushiSwap GitHub: [https://github.com/sushiswap/sushiswap/blob/6aa1d786785a447aa1224280e06ac09e4c82e06f/contracts/SushiToken.sol](https://github.com/sushiswap/sushiswap/blob/6aa1d786785a447aa1224280e06ac09e4c82e06f/contracts/SushiToken.sol)
- Serial Coder Analysis: [https://www.serial-coder.com/post/sushiswap-voting-vulnerability-of-sushi-token-and-its-forks/](https://www.serial-coder.com/post/sushiswap-voting-vulnerability-of-sushi-token-and-its-forks/)
- Valix Consulting: [https://medium.com/valixconsulting/sushiswap-voting-vulnerability-of-sushi-token-and-its-forks-56f220d4c9ba](https://medium.com/valixconsulting/sushiswap-voting-vulnerability-of-sushi-token-and-its-forks-56f220d4c9ba)