Summary

Whitehat nojob reported a critical vulnerability in Port Finance via Immunefi on March 29. If a malicious attacker had exploited the vulnerability, they could have stolen $20-25 million. But because of nojob’s responsible disclosure, no user funds were lost. Port Finance promptly patched the bug and paid the whitehat $180,000 USD and $450,000 in PORT tokens linearly vested over a year. This is the max payout for Port Finance’s bounty program.

Excellent work by nojob for the find and Port Finance for the fix and reward!

Immunefi facilitated this responsible disclosure with their platform. This bugfix review is written by Halborns Piotr, Practice Manager (Solana).

Now, on to an explanation of DeFi lending, Port Finance, and the vulnerability itself.

Intro to Lending

The capital market in the traditional financial system is not easily accessible to the general public – only the big players have the VIP card to access it.

Suppose you are an investor looking to finance your next business venture. One way of doing it is by taking a loan and offering your assets as collateral. The collateralized capital will essentially be frozen and can grow over time. It can also be redeemed at a later date. This is not a risk-free strategy, though. If you are not careful, you may default on your loan payment and lose your collateral.

Lending protocols in DeFi have now democratized access to debt for everyone. Using your digital assets as collateral, you can borrow from these protocols and leverage upon it. As one of the largest DeFi categories, decentralized lending and borrowing has been growing exponentially since late 2020.

Borrowing

The value of the assets you want to borrow is determined with a parameter called LTV (Loan To Value). Although multiple definitions exist, for the purposes of this example we can define it as a ratio of the value of your loan to the value of your collateral. Currently, most lending protocols offer overcollateralized loans only. For instance, if you borrow $60 worth of some cryptocurrency and you provide $100 as collateral, your LTV is $60/$100 = 0.6.

Liquidations

Liquidation is a safety mechanism which protects lenders from negative price volatility. In a nutshell, if for some reason the value of your collateral is insufficient, the liquidators may purchase your collateral at a discount.

Lending protocols usually set target LTVs for their lending pools, and as a borrower, your main risks involve losing your collateral through mismanagement of your position’s LTV.

Cryptocurrency is known for its extreme price volatility, and if your loan goes below the target LTV, you are at risk of having your collateral liquidated.

This is not an ideal outcome, as you will most likely take a considerable loss and pay a liquidation fee (penalty) on top of that. It is then vital to constantly monitor and maintain a healthy collateral ratio for your loans.

Maintaining State

In the DeFi world, the ethos is that shouldn’t be any central entities managing platforms and protocols. Protocol management is often delegated to protocol communities instead. In general, blockchain applications favour the “push over pull” strategy. Rather than doing it in one heavy operation, updating the protocol state is split into several lighter operations that have to be executed in a particular order. This simplifies the application design and incentivizes users to participate in protocol management by rewarding them with tokens or extra perks.

Vulnerability Analysis

Port Finance is a non-custodial money market protocol on Solana. Its goals are to bring a whole suite of interest rate products, including variable rate lending, fixed rate lending, and interest rate swap to the Solana blockchain.

Lending Pools

Port Finance’s lending pools (`Reserve`s) are described with a number of parameters, including `ReserveConfig`:

“`rust

/// Lending market reserve state

#[derive(Clone, Debug, Default, PartialEq)]

pub struct Reserve {

/// Version of the struct

pub version: u8,

/// Last slot when supply and rates updated

pub last_update: LastUpdate,

/// Lending market address

pub lending_market: Pubkey,

/// Reserve liquidity

pub liquidity: ReserveLiquidity,

/// Reserve collateral

pub collateral: ReserveCollateral,

/// Reserve configuration values

pub config: ReserveConfig,

}

“`

“`rust

/// Reserve configuration values

#[derive(Clone, Copy, Debug, Default, PartialEq)]

pub struct ReserveConfig {

/// Optimal utilization rate, as a percentage

pub optimal_utilization_rate: u8,

/// Target ratio of the value of borrows to deposits, as a percentage

/// 0 if use as collateral is disabled

pub loan_to_value_ratio: u8,

/// Bonus a liquidator gets when repaying part of an unhealthy obligation, as a percentage

pub liquidation_bonus: u8,

/// Loan to value ratio at which an obligation can be liquidated, as a percentage

pub liquidation_threshold: u8,

/// Min borrow APY

pub min_borrow_rate: u8,

/// Optimal (utilization) borrow APY

pub optimal_borrow_rate: u8,

/// Max borrow APY

pub max_borrow_rate: u8,

/// Program owner fees assessed, separate from gains due to interest accrual

pub fees: ReserveFees,

/// corresponded staking pool pubkey of deposit

pub deposit_staking_pool: COption<Pubkey>,

}

“`

`loan_to_value_ratio` determines the target LTV for the pool and `liquidation_bonus` determines the discount at which liquidators can buy the liquidated collateral.

Simply put, the value of collateral to buy at a discount is calculated as `collateral_to_be_liquidated * (1 + liquidation_bonus)`. The liquidator pays for `collateral_to_be_liquidated` but they receive `collateral_to_be_liquidated * (1 + liquidation_bonus)`.

User Positions

User positions are described with `Obligation` structs which store data about all their borrows and collateral deposits.

“`rust

/// Lending market obligation state

#[derive(Clone, Debug, Default, PartialEq)]

pub struct Obligation {

/// Version of the struct

pub version: u8,

/// Last update to collateral, liquidity, or their market values

pub last_update: LastUpdate,

/// Lending market address

pub lending_market: Pubkey,

/// Owner authority which can borrow liquidity

pub owner: Pubkey,

/// Deposited collateral for the obligation, unique by deposit reserve address

pub deposits: Vec<ObligationCollateral>,

/// Borrowed liquidity for the obligation, unique by borrow reserve address

pub borrows: Vec<ObligationLiquidity>,

/// Market value of deposits

pub deposited_value: Decimal,

/// Market value of borrows

pub borrowed_value: Decimal,

/// The maximum borrow value at the weighted average loan to value ratio

pub allowed_borrow_value: Decimal,

/// The dangerous borrow value at the weighted average liquidation threshold

pub unhealthy_borrow_value: Decimal,

}

“`

When a user interacts with their collateral, the `deposits` array is updated and when they interact with their borrows, the `borrows` array is updated.

`allowed_borrow_value` denotes the maximum total market value of assets the user can borrow and it is calculated as the sum of the value of all user collaterals multiplied by the relevant pools’ LTVs.

`unhealthy_borrow_value` denotes the threshold market value of borrowed assets at which the user collateral is at risk of liquidation and is calculated as the sum of user collaterals multiplied by the relevant pools’ liquidation thresholds. `unhealthy_borrow_value` should be greater than `allowed_borrow_value`.

Withdrawing Collateral

Each user deposit is recorded in the user’s `Obligation`, updating or adding a relevant `ObligationCollateral` struct. Users can withdraw their collateral, decreasing the `allowed_borrow_value` and `unhealthy_borrow_value`.

The maximum market value of collateral that can be withdrawn from an `Obligation` was calculated with the `Obligation::max_withdraw_value`.

“`rust

/// Calculate the maximum collateral value that can be withdrawn

pub fn max_withdraw_value(&self) -> Result<Decimal, ProgramError> {

let required_deposit_value = self

.borrowed_value

.try_mul(self.deposited_value)?

.try_div(self.allowed_borrow_value)?;

if required_deposit_value >= self.deposited_value {

return Ok(Decimal::zero());

}

self.deposited_value.try_sub(required_deposit_value)

}

“`

The maximum value to be withdrawn was calculated as the delta of the total user deposit value, and the total user deposit value multiplied by the borrow to allowed borrow ratio.

Liquidating Collateral

If the `borrow_value` of an obligation is greater than the `unhealthy_borrow_value`, the obligation is liquidatable. Liquidators can buy the obligation collateral at a discount defined by the collateral reserve’s `liquidation_bonus`. A maximum of 50% of the total `borrowed_value` can be withdrawn in one go. The result is scaled by the `bonus_rate` for the collateral’s reserve and transferred to the liquidator’s account.

The Exploit

Before Port Finance had patched the bug, a malicious user could have withdrawn all their obligation collaterals without paying off their full debt under the following assumptions:

– They find some reserve R1 with high liquidation `bonus_rate` and some reserve R2 with high LTV such that the sum of reserve R1 `bonus_rate` and reserve R2 LTV is greater than 100%.

– They create an obligation and deposit some token T1 as collateral to reserve R1.

– They deposit some token T2 as collateral to reserve R2. The value of the T2 deposit should be greater than the value of the T1 deposit by several orders of magnitude, e.g. 3.

– They borrow token T2 from the reserve with high LTV. The borrow value should be similar to the value of the T1 token deposit.

– They withdraw the entire T2 token deposit. This makes their obligation liquidatable because the T2 token borrow is heavily undercollateralized now.

– They liquidate their obligation. Because the T2 token borrow value is similar to the value of the T1 token deposit and the R1 reserve has high `bonus_rate`, the **obligation collateral is liquidated at a quicker pace than the borrow is being repaid, and the malicious user drains their T1 token deposit before they pay off their borrow in full**.

A total of $20-25 million could have been stolen.

Vulnerability Fix

The `Obligation::max_withdraw_value` function was fixed by introducing the `withdraw_collateral_ltv` parameter denoting the LTV of reserve corresponding to the withdrawn collateral and calculating the maximum withdraw value as the ratio of the delta of the allowed borrow value and the borrowed value, and the reserve LTV.