Boost _ Folks Finance 33778 - [Smart Contract - Medium] The loan creation process can be griefed

Submitted on Mon Jul 29 2024 08:48:29 GMT-0400 (Atlantic Standard Time) by @JCN2023 for Boost | Folks Finance

Report ID: #33778

Report type: Smart Contract

Report severity: Medium

Target: https://testnet.snowtrace.io/address/0x6628cE08b54e9C8358bE94f716D93AdDcca45b00

Impacts:

  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Brief/Intro

A loan is required in order to perform core operations (depositing, borrowing) in the folks finance protocol. It is the user's responsibility to supply an arbitrary loanId during the createLoan function call. A bad actor can front-run any loan creation operation seen on the Hub chain and create a loan using the loanId seen in any user's tx. Therefore, the bad actor is able to grief the loan creation of any other user, preventing them from being able to interact with the core operations of the protocol for an arbitrary amount of time.

Bug Description

Ignoring cross-chain components, the execution flow for loan creation is as follows: SpokeCommon::createLoan -> router/adapter/hub interactions -> LoanManager::createUserLoan. It is important to note that all the loan state is stored on the Hub chain, so the LoanManager contract on the Hub chain will store the loan information for all users, even if the user is interacting via a different Spoke chain.

When creating a loan, a user must supply a loanId that will be the identifier for the loan to be created:

SpokeCommon::createLoan

The loanId is then validated to be inactive, i.e. no other user should have used this loanId yet.

LoanManager::createUserLoan

LoanManagerState::isUserLoanActive

Since this loanId value is user defined, any bad actor can front-run other users' createLoan transactions and create loans using those users' loanIds. This will result in the users' transactions reverting on line 49 in LoanManager.sol.

Impact

A bad actor can consistently grief other users' createLoan transactions, preventing those users from interacting with the core components of the protocol for an arbitrary amount of time. The bad actor can lower the gas costs of this exploit by submitting their createLoan tx directly via the Hub chain (utilizing the HubAdapter) instead of interacting via a Spoke chain (triggering cross chain communications).

I would recommend implementing an loanId state variable that is utilized and incremented every time a new loan is created. This would be more gas intensive, but would limit the number of arbitrary values that users can supply to functions, which will in turn decrease the number of possible attack vectors.

Proof of concept

Proof of Concept

To run foundry POC:

  • add test file to test/ directory of a foundry repo

  • add AVAX_FUJI_RPC_URL variable as environment var or in .env file

  • run test with forge test --mc FolksPOC_GriefLoanCreation

Last updated

Was this helpful?