The `env!` macro won't work once the Lavarage program is deployed on-chain, leading to the `liquidate` function being permanently DoSed

[c4-bot-4]

Lines of code

https://github.com/code-423n4/2024-04-lavarage/blob/9e8295b542fb71b2ba9b4693e25619585266d19e/libs/smart-contracts/programs/lavarage/src/processor/liquidate.rs#L23

Vulnerability details

Impact

The liquidate function will be permanently DoSed, opening the possibility for borrowers having under-collateralized loans, which will lead to lenders experiencing significant losses

Proof of Concept

The current implementation of the liquidate function assigns the value of oracle_pubkey_check to the environment variable ORACLE_PUB_KEY, by reading it using the env! macro provided in the Rust standard library.

let oracle_pubkey_check = Pubkey::from_str(env!("ORACLE_PUB_KEY")).expect("Invalid public key");

This will work fine for local deployments and for running tests, as the environment variable will be taken from the local machine. However, given that the env! call is performed at runtime, when the Lavarage program is deployed on-chain, this will lead to that environment variable not being able to be read, as at that point, the program will be actually running within the Solana network's execution environment. What this means is that on-chain, the liquidate function will be permanently non-callable, making it impossible to liquidate any borrower, even if their loans become under-collateralized.

Tools Used

Manual review

Recommended Mitigation Steps

Create a config account that will be used for storing the oracle public key instead of using an environment variable. This article does a great job of explaining how this can be achieved.

Assessed type

DoS

[c4-sponsor]

piske-alex (sponsor) confirmed

[c4-sponsor]

piske-alex (sponsor) disputed

[piske-alex]

I haven't tested it in prod yet but according to rustdocs env! reads the variable at compile time

[alcueca]

Upon deployment, the code will be compiled into BPF, including the public key taken from the deployment environment. The linked article offers a way of implementing environment variables in Solana whose content can change after deployment.

[c4-judge]

alcueca marked the issue as unsatisfactory: Invalid