Salty.IO - ReadyPlayer2's results

Lines of code

https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/dao/DAOConfig.sol#L45 https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/dao/DAO.sol#L278 https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/staking/Staking.sol#L65 https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/staking/StakingConfig.sol#L18 https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/staking/StakingConfig.sol#L34 https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/dao/Proposals.sol#L155

Vulnerability details

Impact

In the DAO which mainly consists of Proposals.sol and DAO.sol there could be an unforseen period of double voting, initiated by a malicious threat actors. This is due to a number of factors:

Firstly that the default unstake time in Staking.sol is 2 weeks. Secondly that in the staking config a decrease in this time will result in 1 week. Thirdly that the minimum time for a ballot/voting period is 10 days. Mainly that users can unstake with active governance activity.

However knowing this a malicious user could propose that the unstaking period be reduced to 1 week, which could allow voters to vote before unstaking, then vote again for the same ballot with the re-staked 20%(As of default) of their power from a different account.

As of default settings, such an attack is costly and improbable, however there are many concerns once the dao is functioning. The variations in which the minimum unstake percentage is increased could increase the likelihood of such an attack.

The impact of such an attack is mainly that a user that is no longer part of the protocol has cast a vote/proposed a vote before leaving the protocol. The worst case scenario is one in which the user re-stake to vote again. This could result in an unfair edge for a user since even though they lost their stake, it could be outweighed by a transfer salt to their address.

Proof of Concept

The PoC will guide through the most probable variation from current defaults:

Bob is a user. Alice is malicious user.

Step 1

Bob stakes into the protocol by calling stakeSALT

Step 2

Bob has staked enough to open a Ballot, Bob proposes that the minUnstakeWeeks be decreased to 1 week(7 days) by proposing a parameter ballot.

Step 3

After 10 days Bobs proposal wins and bob has decreased the minimum number of unstake weeks.

Step 4

Alice Also stakes into the protocol and has enough to propose a ballot. So Alice proposes a ballot to transfer salt to her account.

Step 5

Alice casts a vote for her proposal.

Step 6

Alice unstakes from the protocol and finalizes on the end of day 7 before her ballot has ended.

This is already a problem, Alice has a ballot and has voted, but is no longer part of the protocol.

Step 7

Alice then transfers her remaining salt to another address, and re-stakes into the protocol. Casting a final vote on her proposal.

Tools Used

Manual review

Recommended Mitigation Steps

I would recommend that users should not be able to unstake in the protocol if they have any active governance activity. This is the only mitigation I would recommend, as such an attack could have more costly variations, and changing default parameters may not account for all of them.

Assessed type

Governance