Core Contracts

Summary

The Chainlink Function is a two-step solution in which a request is created and after some time, the request is fulfilled. The fulfillment happens through a callback which means it's a new transaction and not part of the request transaction.

Both contracts rely on Chainlink Functions to get RWA prices through external calls.

Vulnerability Details

Due to Chainlink Functions nature, each request must be handled separately considering the particular ID that is generated upon request creation. The problem is the protocol doesn't use this ID in their fulfillment process.

This means the transaction order can be unintentionally manipulated.

RAACHousePrices

On the RAACHousePriceOracle, once the request is performed the _ beforeFulfillfunction is called to update lastHouseIdwith the ID of the RWA from the request. As soon as the request is fulfilled, the result is pushed through the setHousePrice function and stored on the RAACHousePrices.sol contract using that particular ID stored after the request is initiated.

The RAACHousePricescontract stores the price and updates the lastUpdateTimestamp. This variable is used to check for staleness in other protocol functionalities. Given this information, we can assume all the RWAs are updated on the same window, otherwise, the staleness check is broken. By doing this, the protocol is totally vulnerable to transaction reordering.

RAACPrimeRateOracles

The RAACPrimeRateOraclesare also vulnerable, but they set rates on the LiquidityPool.

Impact

First Scenario

-> Requests

Tx1 is performed with the rwaId == 7 and the rwaValue were 8m. But after some valorization, the expected to be returned is 10m. So, the lastHouseIdis set to id 7.
Tx2 is performed with the rwaId == 77 and the rwaValue expected to be returned is 500k. So, the lastHouseId is set to 77.

-> Fulfillment

Tx1 answer is received, the _processResponse is called, and the lastHouseIdis updated with the price. The problem is, that the received value is for the rwaId 7, but the rwaId being updated is 77.
Result: rwaId7 will be stale and will not reflect the correct value. The owner of the rwaId will have a small window in which his rwa will be overpriced.

Tx2 answer will received and update the rwaId 77 with the correct value.

Second Scenario

Tx1 is performed with the rwaId == 7 and the rwaValue were 8m. But after some valorization, the expected to be returned is 10m. So, the lastHouseIdis set to id 7.
Tx2 is performed with the rwaId == 66 and the rwaValue expected to be returned is 500k. So, the lastHouseId is set to 66.

A malicious user, maybe the owner of the rwaId 66 Is waiting for these calls. So they reorder the transaction on the mempool.

Tx2 is received first and updates the rwaId 66 to 500k, as it should be. However, right after the Tx1 is received and updated the rwaId 66 again, this time to 10m.

Now, the owner of the rwaId can take loans over the price of its overpriced token. While the rwaId remains stale.

Protocol money and users' assets are at risk.

Tools Used

Code Review

Recommendations

Use mapping with requestId to Request struct to store requests and nftId's. Call the housePrices.setHousePrice(lastHouseId, price);using the information stored on the mapping. This way you can make sure the values updated correspond to the nftId that is being updated.