Hubble contest - cccz's results

Multi-collateral/Cross-Margin Perpetual Futures on Avalanche.

General Information

Platform: Code4rena

Start Date: 17/02/2022

Pot Size: $75,000 USDC

Total HM: 20

Participants: 39

Period: 7 days

Judges: moose-code, JasoonS

Total Solo HM: 13

Id: 89

League: ETH

Hubble

Findings Distribution

Researcher Performance

Rank: 26/39

Findings: 2

Award: $250.24

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: hyh

Also found by: 0x1f8b, WatchPug, cccz, csanuragjain, defsec, hubble, leastwood, pauliax, ye0lde

Labels

bug
duplicate
2 (Med Risk)

Awards

107.9164 USDC - $107.92

External Links

Lines of code

https://github.com/code-423n4/2022-02-hubble/blob/main/contracts/Oracle.sol#L33

Vulnerability details

Impact

On Oracle.sol, we are using latestRoundData, but there is no check if the return value indicates stale data.

(,answer,,,) = AggregatorV3Interface(chainLinkAggregatorMap[underlying]).latestRoundData();

This could lead to stale prices according to the Chainlink documentation:

https://docs.chain.link/docs/historical-price-data/#historical-rounds https://docs.chain.link/docs/faq/#how-can-i-check-if-the-answer-to-a-round-is-being-carried-over-from-a-previous-round

Proof of Concept

https://github.com/code-423n4/2022-02-hubble/blob/main/contracts/Oracle.sol#L33

Tools Used

None

Consider adding missing checks for stale data.

For example:

(uint80 roundID, int256 answer, , uint256 timestamp, uint80 answeredInRound) = AggregatorV3Interface(chainLinkAggregatorMap[underlying]).latestRoundData(); require(answeredInRound >= roundID, "Stale price"); require(timestamp != 0,"Round not complete"); require(answer > 0,"Chainlink answer reporting 0");

#0 - atvanguard

2022-02-24T08:30:30Z

Duplicate of #46

Awards

142.3223 USDC - $142.32

Labels

bug
duplicate
QA (Quality Assurance)

External Links

Lines of code

https://github.com/code-423n4/2022-02-hubble/blob/main/contracts/VUSD.sol#L7

Vulnerability details

Impact

Same as https://github.com/code-423n4/2022-01-livepeer-findings/issues/193

The VUSD contract inherits from the ERC20PresetMinterPauser contract

Using the mint() function of ERC20PresetMinterPauser, an address with MINTER_ROLE can mint an arbitrary amount of tokens.

If the private key of the deployer or an address with the MINTER_ROLE is compromised, the attacker will be able to mint an unlimited amount of VUSD tokens.

We believe this is unnecessary and poses a serious centralization risk.

Proof of Concept

https://github.com/code-423n4/2022-02-hubble/blob/main/contracts/VUSD.sol#L7

Tools Used

None

Consider removing the MINTER_ROLE, make the VUSD only mintable by the owner, and make the MarginAccount contract to be the owner and therefore the only minter.

#0 - atvanguard

2022-02-24T08:12:54Z

Duplicate of #48

#1 - JeeberC4

2022-03-24T20:33:56Z

Since this issue was downgraded to a QA level, and the warden did not submit a separate QA report, we've renamed this one to "QA report" for consistency. The original title, for the record, was MINTER_ROLE can be granted by the deployer of VUSD and mint arbitrary amount of tokens

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