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:
The loanId
is then validated to be inactive, i.e. no other user should have used this loanId
yet.
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' loanId
s. 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).
Recommended Mitigation
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 repoadd
AVAX_FUJI_RPC_URL
variable as environment var or in.env
filerun test with
forge test --mc FolksPOC_GriefLoanCreation