Olympus DAO contest - reassor's results

Version 3 of Olympus protocol, a decentralized floating currency.

General Information

Platform: Code4rena

Start Date: 25/08/2022

Pot Size: $75,000 USDC

Total HM: 35

Participants: 147

Period: 7 days

Judge: 0xean

Total Solo HM: 15

Id: 156

League: ETH

Olympus DAO

Findings Distribution

Researcher Performance

Rank: 9/147

Findings: 4

Award: $2,324.37

🌟 Selected for report: 1

🚀 Solo Findings: 1

Findings Information

🌟 Selected for report: okkothejawa

Also found by: Trust, datapunk, reassor

Labels

bug
duplicate
2 (Med Risk)
sponsor confirmed

Awards

347.2615 DAI - $347.26

External Links

Lines of code

https://github.com/code-423n4/2022-08-olympus/blob/277535739c465c75d37c33d706ab76365df2aade/src/modules/PRICE.sol#L165-L166 https://github.com/code-423n4/2022-08-olympus/blob/277535739c465c75d37c33d706ab76365df2aade/src/modules/PRICE.sol#L171-L172

Vulnerability details

Impact

Function OlympusPrice.getCurrentPrice returns ohm price in the reserve asset by retrieving prices of ohm and reserve asset from Chainlink. The issue is that the accepted timeframe of ohm price is 3 * uint256(observationFrequency):

if (updatedAt < block.timestamp - 3 * uint256(observationFrequency)) revert Price_BadFeed(address(_ohmEthPriceFeed));

but reserve asset is just uint256(observationFrequency):

if (updatedAt < block.timestamp - uint256(observationFrequency)) revert Price_BadFeed(address(_reserveEthPriceFeed));

This mismatch might lead to price inaccuracies and errors while the price of ohm is old comparing to the price of reserve asset. The accepted price timeframe should be exactly the same for both ohm and reserve asset.

Proof of Concept

modules/PRICE.sol:

Tools Used

Manual Review / VSCode

It is recommended to set exactly the same timeframe for accepting chainlink's prices for ohm and reserve asset.

#0 - Oighty

2022-09-06T18:36:20Z

Duplicate of #391

#1 - 0xean

2022-09-19T13:20:26Z

closing as dupe

Findings Information

🌟 Selected for report: reassor

Labels

bug
2 (Med Risk)

Awards

1905.4132 DAI - $1,905.41

External Links

Lines of code

https://github.com/code-423n4/2022-08-olympus/blob/2a0b515012b4a40076f6eac487f7816aafb8724a/src/policies/Governance.sol#L265-L289

Vulnerability details

Impact

Contract OlympusGovernance allows controlling protocol through on-chain governing. The issue is that once proposal is active it does not expire, which means that until the new proposal will be selected, anyone can vote on existing one and potentially execute it when it might cause harm to the protocol.

Scenario:

  1. New proposal has been submited, endorsed and activated.
  2. Users vote, but the quroum is not being achieved.
  3. The proposal is active until new one is getting submitted.
  4. 6 months elapses and the current active proposal might cause serious harm to the protocol (since it was created long time ago).
  5. Malicious actor votes and executes proposal causing harm to the protocol.

Proof of Concept

Governance.sol:

Tools Used

Manual Review / VSCode

It is recommended to add expiration for the active proposal for example 2 weeks. After that time it should be possible to reject proposal and users should be able to reclaim VOTES tokens.

#0 - fullyallocated

2022-09-04T03:11:09Z

Duplicate of #376

#1 - 0xean

2022-09-20T00:47:08Z

I don't think this is an exact dupe of #376

I believe the warden is simply stating that an active proposal stays active if not replaced. There is not expiration of a proposal once it becomes active, so theoretically if the governance process is inactive a very stale proposal could get executed.

Findings Information

Awards

11.0311 DAI - $11.03

Labels

bug
duplicate
2 (Med Risk)
sponsor confirmed

External Links

Lines of code

https://github.com/code-423n4/2022-08-olympus/blob/277535739c465c75d37c33d706ab76365df2aade/src/modules/PRICE.sol#L161 https://github.com/code-423n4/2022-08-olympus/blob/277535739c465c75d37c33d706ab76365df2aade/src/modules/PRICE.sol#L170

Vulnerability details

Impact

Protocol uses Chainlink as an oracle for retrieving prices for the assets.

Function OlympusPrice.getCurrentPrice retrieves price using latestRoundData but the implementation is missing essential security checks which can result in stale and incorrect prices being returned.

Proof of Concept

modules/PRICE.sol:

Tools Used

Manual Review / VSCode

It is recommended to add checks on the returned data of latestRoundData with proper revert messages if the price is stale or the round is incomplete, for example:

( roundId, rawPrice, , updateTime, answeredInRound ) = _ohmEthPriceFeedk.latestRoundData(); require(rawPrice > 0, "price <= 0"); require(updateTime != 0, "incomplete round"); require(answeredInRound >= roundId, "stale price");

#0 - Oighty

2022-09-06T18:57:25Z

Duplicate. See comment on #441.

List

Low Risk

  1. Missing zero address checks
  2. Critical address change
  3. Missing events

Non-Critical Risk

  1. Missing indexed events
  2. Missing pause functionality
  3. Usage of not well-tested solidity version might contain undiscovered vulnerabilities
  4. Missing/incomplete natspec comments

1. Missing zero address checks

Risk

Low

Impact

Multiple contracts do not check for zero addresses which might lead to loss of funds, failed transactions and can break the protocol functionality.

Proof of Concept

Kernel.sol:

modules/MINTR.sol:

modules/RANGE.sol:

policies/Heart.sol:

policies/Governance.sol:

policies/BondCallback.sol:

policies/Operator.sol:

Tools Used

Manual Review / VSCode

It is recommended to add zero address checks for listed parameters.

2. Critical address change

Risk

Low

Impact

Changing critical addresses such as ownership should be a two-step process where the first transaction (from the old/current address) registers the new address (i.e. grants ownership) and the second transaction (from the new address) replaces the old address with the new one. This gives an opportunity to recover from incorrect addresses mistakenly used in the first step. If not, contract functionality might become inaccessible.

Proof of Concept

Kernel.sol:

Tools Used

Manual Review / VSCode

It is recommended to implement two-step process for changing ownership.

3. Missing events

Risk

Low

Impact

Multiple contracts are not implementing events for critical functions. Lack of events makes it difficult for off-chain applications to monitor the protocol.

Proof of Concept

policies/Heart.sol:

policies/Governance.sol:

policies/BondCallback.sol:

policies/Operator.sol:

Tools Used

Manual Review / VSCode

It is recommended to add missing events to listed functions.

4. Missing indexed events

Risk

Non-Critical

Impact

Protocol implements multiple events but does not properly index parameters for all of them. Lack of indexed parameters for events makes it difficult for off-chain applications to monitor the protocol.

Proof of Concept

modules/PRICE.sol:

modules/RANGE.sol:

policies/Heart.sol:

Tools Used

Manual Review / VSCode

It is recommended to add indexed keyword to listed events parameters.

5. Missing pause functionality

Risk

Non-Critical

Impact

Contracts are missing pause functionality that could be used in case of security incidents and would block executing selected functions while the contract is paused.

Proof of Concept

Tools Used

Manual Review / VSCode

It is recommended to add functionality for pausing contracts and go through all publicly/externally accessible functions to decide which one should be forbidden from running while the contracts are paused.

6. Usage of not well-tested solidity version might contain undiscovered vulnerabilities

Risk

Non-Critical

Impact

Using the latest versions might make contracts susceptible to undiscovered compiler bugs.

Proof of Concept

Kernel.sol:pragma solidity 0.8.15; utils/KernelUtils.sol:pragma solidity 0.8.15; modules/TRSRY.sol:pragma solidity 0.8.15; modules/VOTES.sol:pragma solidity 0.8.15; modules/MINTR.sol:pragma solidity 0.8.15; modules/PRICE.sol:pragma solidity 0.8.15; modules/INSTR.sol:pragma solidity 0.8.15; modules/RANGE.sol:pragma solidity 0.8.15; policies/PriceConfig.sol:pragma solidity 0.8.15; policies/Governance.sol:pragma solidity 0.8.15; policies/Heart.sol:pragma solidity 0.8.15; policies/Operator.sol:pragma solidity 0.8.15; policies/VoterRegistration.sol:pragma solidity 0.8.15; policies/TreasuryCustodian.sol:pragma solidity 0.8.15; policies/BondCallback.sol:pragma solidity 0.8.15;

Tools Used

Manual Review / VSCode

It is recommended to use more stable and tested solidity version such as 0.8.10.

7. Missing/incomplete natspec comments

Risk

Non-Critical

Impact

Multiple contracts are missing natspec comments which makes code more difficult to read and prone to errors.

Proof of Concept

Kernel.sol:

utils/KernelUtils.sol:

modules/INSTR.sol:

modules/MINTR.sol:

modules/PRICE.sol:

modules/RANGE.sol:

modules/TRSRY.sol:

modules/VOTES.sol:

policies/TreasuryCustodian.sol:

policies/VoterRegistration.sol:

policies/PriceConfig.sol:

policies/Heart.sol:

policies/Governance.sol:

policies/BondCallback.sol:

policies/Operator.sol:

Tools Used

Manual Review / VSCode

It is recommended to add missing natspec comments.

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter