Core Contracts

Summary

Proposals that need a predecessor can be griefed

Vulnerability Details

When _queueProposal hashes the new proposal it uses bytes32(0) as predecessor:

This means that all proposals are set to have no predecessor, even the ones that might actually need one.

This is dangerous as some will really do need a predecessor and those might be either bricked or exploited if executed without their predecessor.

Example:

There are 2 proposals:

• 1st to create and set a gauge factory, deploy specific gauge and deposit a tiny amount of funds in order to prevent first depositor attack

• 2nd is to distribute some funds around, with 10% to the new gouge to start it and the rest 90% to the rest of the gauges

1. Both proposals pass and are queued at the same time

2. However right as when they become executable a malicious user executes the second one first, sending the funds to a contract address of a contract that is not yet deployed

3. When executing the second proposal the factory may deploy the contract to another address or brick the internal accounting as it already has funds

Another example would be for the first to fail and the second to pass. Then the second may not be executable (or if it can it's even worse), due to the 10% being sent to a not yet deployed contract.

Impact

Proposals that require 2 TX can be exploited by malicious users
Not every proposal will require a predecessor, but the ones that do may be griefed by malicious users.

Tools Used

Manual review

Recommendations

Have the predecessor available to be set by the proposal maker.