Lines of code

https://github.com/code-423n4/2022-02-anchor/blob/7af353e3234837979a19ddc8093dc9ad3c63ab6b/contracts/anchor-token-contracts/contracts/gov/src/contract.rs#L204-L206

Vulnerability details

Timelock period in Governance Contract does not have minimum Threshold delay

The current "timelock_period" config value is set to a low value of 40327 (around 11 hours). And this value can be set by the owner to even lower values.

Impact

Timelocks play an important role in Governance contracts to allow protocol users to react timely if a change made is done erronously or is not in the best interest of protocol and its users.

Both the instantiate and update_config functions in anchor-token-contracts/contracts/gov/src/contract.rs do not restrict that timelock_period (i.e., execution delay period) is greater or equal to some minimum threshold. The owner/admin can set a very low value, and any malicious/erronous changes proposed through voting could be executed immediately if timelock_period is not set appropriately.

Severity justification

Raising this issue as Medium risk because

The TVL of the protocol is 15+B UST
current value of timelock_period is low and can be set lower by governance owner

Proof of Concept

Contract : anchor-token-contracts/contracts/gov/src/contract.rs Function : pub fn update_config(...) Line 204 :

        if let Some(timelock_period) = timelock_period {
            config.timelock_period = timelock_period;
        }

Recommended Mitigation Steps

Define a minimum threshold value like below. const MIN_TIMELOCK_PERIOD: usize = 86400;

And add a check in instantiate and update_config functions to ensure that timelock_period is greater or equal than a minimum threshold value that allows Anchor users to act timely against any issue that protocol could have when changes are made. Some example values of timelocks period used in well known protocols are:

Uniswap: 48-hours
Compound: 48-hours
Aave: 24-hours

code-423n4 / 2022-02-anchor-findings