You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Users can pass in malicious oracle addresses during createLendOrder() and createBorrowOrder()
Summary
In debita V3, the protocol supports functionality for users to create lend offers and borrow offers and specify oracle addresses to retrieve the price of collateral/principle tokens instead of just defaulting to a fixed ratio (number of collateral tokens worth per principle token, vice-versa).
The protocol provides various oracle contracts such as DebitaChainLink, DebitaPyth and MixOracle. It is intended for users to provide the address of these oracle contracts during createLendOffer() and createBorrowOffer().
However, there is a lack of validation checks on the addresses provided as oracles. This means that users can use any arbitrary contract as the oracle and still create their lend/ borrow offer, proceed to have their orders matched, etc.
The text was updated successfully, but these errors were encountered:
sherlock-admin3
changed the title
Smooth Butter Worm - Users can pass in malicious oracle addresses during createLendOrder() and createBorrowOrder()
rilwan99 - Users can pass in malicious oracle addresses during createLendOrder() and createBorrowOrder()
Dec 12, 2024
rilwan99
Medium
Users can pass in malicious oracle addresses during createLendOrder() and createBorrowOrder()
Summary
In debita V3, the protocol supports functionality for users to create lend offers and borrow offers and specify oracle addresses to retrieve the price of collateral/principle tokens instead of just defaulting to a fixed ratio (number of collateral tokens worth per principle token, vice-versa).
The protocol provides various oracle contracts such as DebitaChainLink, DebitaPyth and MixOracle. It is intended for users to provide the address of these oracle contracts during
createLendOffer()
andcreateBorrowOffer()
.However, there is a lack of validation checks on the addresses provided as oracles. This means that users can use any arbitrary contract as the oracle and still create their lend/ borrow offer, proceed to have their orders matched, etc.
https://github.com/sherlock-audit/2024-11-debita-finance-v3/blob/main/Debita-V3-Contracts/contracts/DebitaBorrowOffer-Factory.sol#L75-L88
https://github.com/sherlock-audit/2024-11-debita-finance-v3/blob/main/Debita-V3-Contracts/contracts/DebitaLendOfferFactory.sol#L124-L138
Root Cause
Due to a lack of validation on the addresses provided, users can pass in malicious oracles to inflate the value of their collateral/ principle tokens.
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
address _oracleID_Collateral
https://github.com/sherlock-audit/2024-11-debita-finance-v3/blob/main/Debita-V3-Contracts/contracts/DebitaBorrowOffer-Factory.sol#L86
https://github.com/sherlock-audit/2024-11-debita-finance-v3/blob/main/Debita-V3-Contracts/contracts/DebitaV3Aggregator.sol#L308-L310
Impact
No response
PoC
No response
Mitigation
No response
The text was updated successfully, but these errors were encountered: