Borrowers can avoid the payment of the 20% interest share fee on their accumulated interest
Proof of Concept
The current implementation of the repay_sol function sends a 20% interest share fee to the specified fee_receipient account that is passed in to it. However, as it can be seen, that account is a user specified one:
/// CHECK: We just want the value of this account
#[account(mut)]
pub fee_receipient: UncheckedAccount<'info>,
What this means, is that the user can take advantage of that and avoid the payment of an interest share fee, by simply passing in a public key that is controlled by them for that value. It is unclear who exactly is supposed to be the on the receiving end for the fee payment, but what's important is that that they can easily be easily be prevented from receiving it.
Tools Used
Manual review
Recommended Mitigation Steps
Apply some restrictions on the fee_receipient public key value. For example, you can make it be a property of the Pool struct that is set on the creation of each new trading pool by its operator.
Lines of code
https://github.com/code-423n4/2024-04-lavarage/blob/9e8295b542fb71b2ba9b4693e25619585266d19e/libs/smart-contracts/programs/lavarage/src/processor/swapback.rs#L185 https://github.com/code-423n4/2024-04-lavarage/blob/9e8295b542fb71b2ba9b4693e25619585266d19e/libs/smart-contracts/programs/lavarage/src/processor/swapback.rs#L192 https://github.com/code-423n4/2024-04-lavarage/blob/9e8295b542fb71b2ba9b4693e25619585266d19e/libs/smart-contracts/programs/lavarage/src/context/repay_sol.rs#L23
Vulnerability details
Impact
Borrowers can avoid the payment of the 20% interest share fee on their accumulated interest
Proof of Concept
The current implementation of the
repay_sol
function sends a 20% interest share fee to the specifiedfee_receipient
account that is passed in to it. However, as it can be seen, that account is a user specified one:What this means, is that the user can take advantage of that and avoid the payment of an interest share fee, by simply passing in a public key that is controlled by them for that value. It is unclear who exactly is supposed to be the on the receiving end for the fee payment, but what's important is that that they can easily be easily be prevented from receiving it.
Tools Used
Manual review
Recommended Mitigation Steps
Apply some restrictions on the
fee_receipient
public key value. For example, you can make it be a property of thePool
struct that is set on the creation of each new trading pool by its operator.Assessed type
Invalid Validation