Zaros Part 1

Summary

The only external oracle in use in this entire protocol is Chainlink. The implementation of a redundant/backup oracle(s) with a voting mechanism for price resolution will enable us to have robust price reporting even in the event that chainlink goes down or reports faulty prices.

https://github.com/Cyfrin/2024-07-zaros/blob/d687fe96bb7ace8652778797052a38763fbcbb1b/src/external/chainlink/ChainlinkUtil.sol#L26-L76

Vulnerability Details

Clearly, chainlink-adjacent contracts are the only source of retrieving external price feeds. Currently, chainlink implements a 4-of-8 multisig in order to sign transactions. Should four wallets ever be compromised or worse, used maliciously by the original owners of chainlink, then the entire price reporting functionality of this protocol is bricked.

Potential multisig issues aside, retrieving the price from a single point of entry carries other issues such as flash loan attacks. Consider the following:

1. Attacker identified a low liquidity market which the Chainlink oracle is pointing at

2. low liquidity market is subject to a flash loan attack

3. Zaros users interact with said market during a period of volatility, retrieving a highly fluctuating price from our price feeds, potentially jeopardizing user funds and eroding user trust.

With redundancy amongst oracle feeds, extreme outliers like the above could be identified and tossed out to prevent faulty reporting from compromised soruces.

Impact

While chainlink has the potential of completely bricking the price reporting mechanisms behind this protocol, it is still fairly unlikely to happen. Regardless, considering the magnitude of potential consequences, this vulnerability should be a priority to resolve.

Tools Used

Manual Review

Recommendations

Implement redundant oracle(s) and price feeds. Implement a voting mechanism that tosses out extreme outliers.