If a token has primarySourceCount == 3, at least 2 valid prices should be given in order to get a price
Summary
If a token has primarySourceCount == 3`, at least 2 valid prices should be given in order to get a price, as only 1/3 valid oracles is insufficient and has security flaws.
Vulnerability Detail
If a token has a primarySourceCount == 3, there should be a minimum of at least 2 of them providing a valid price in order to be used in the project. If an oracle malfunctions and has an outlier price, a malicious user can make use of it and drain assets from the pool. Usually, the tx would not pass as it will break the deviation threshold, however this can be bypassed. The contract will attempt to get prices from all 3 oracles, however the malicious user can DDOS the relayers of the 2 oracles which do not suit him. Since the 2 properly functioning oracles are now DDOSed, the only supposedly valid price we have is of the malfunctioning oracle. The malicious user can now make use of this price to his advantage.
Same thing could happen if there are primarySourceCount == 2, however both allowing the getPrice to work only with 1 valid price and always needing 2 values hides risks and I believe the protocol should choose which risk they are willing to take.
Impact
In case only 1/3 of the oracles malfunctions, malicious user can make use of it. Since the likelihood of such occurrence is low, but the impact is critical, I believe it is a valid medium.
deadrxsezzz
medium
If a token has primarySourceCount == 3, at least 2 valid prices should be given in order to get a price
Summary
If a token has primarySourceCount == 3`, at least 2 valid prices should be given in order to get a price, as only 1/3 valid oracles is insufficient and has security flaws.
Vulnerability Detail
If a token has a
primarySourceCount == 3, there should be a minimum of at least 2 of them providing a valid price in order to be used in the project. If an oracle malfunctions and has an outlier price, a malicious user can make use of it and drain assets from the pool. Usually, the tx would not pass as it will break the deviation threshold, however this can be bypassed. The contract will attempt to get prices from all 3 oracles, however the malicious user can DDOS the relayers of the 2 oracles which do not suit him. Since the 2 properly functioning oracles are now DDOSed, the only supposedly valid price we have is of the malfunctioning oracle. The malicious user can now make use of this price to his advantage. Same thing could happen if there areprimarySourceCount == 2,however both allowing thegetPriceto work only with 1 valid price and always needing 2 values hides risks and I believe the protocol should choose which risk they are willing to take.Impact
In case only 1/3 of the oracles malfunctions, malicious user can make use of it. Since the likelihood of such occurrence is low, but the impact is critical, I believe it is a valid medium.
Code Snippet
https://github.com/sherlock-audit/2023-04-blueberry/blob/main/blueberry-core/contracts/oracle/AggregatorOracle.sol#L104-#L165
Tool used
Manual Review
Recommendation
If a token has 3 primary Oracles used, make sure at least 2 of them send back a valid price