Vulnerability disclosure 2023–06–06

Silo

Published in

Silo

6 min readJun 6, 2023

Summary

On April 27, 2023, a whitehat submitted a vulnerability report via Immunefi.
The report showed that in markets with $0 in deposits for any of the assets, it was possible to manipulate utilization rate to points above 100%, increasing interest rates to extremely high levels.
The core team identified the interest rate model contract (IRMV1) as the source of the vulnerability.
A fix was coded into a new interest rate model contract (IRMV2) and deployed.
Certora confirmed IRMV2 fixed the vulnerability and that no other exploit vectors were possible. Read Certora report here.
No attacks were carried out, no user funds were lost, no protocol funds were compromised.
The Silo protocol is now more secure and functioning normally.

Bounty and comments

We paid out a bounty of 100,000 USDC to the whitehat for finding a critical vulnerability. We appreciate the work of kankodu and invite all whitehats to sift through the code again and submit reports via our bug bounty program.

We are grateful for the Certora team, who reviewed the shipped fix (IRMv2) manually to confirm the vulnerability was fixed and made sure no other attack vectors were possible.

Although a security vulnerability was spotted in one smart contract, Silo protocol’s code is now more battle tested than ever. The vulnerability is fixed and no one was affected by it. This incident provided our team with a great opportunity to review our codebase again, and then have it vetted by top-class security researchers.

Security has always been our utmost priority, and we are now more confident than ever in the resilience of the Silo protocol.

Chronology

On April 27, a whitehat shared a concern that, in markets with $0 in deposits for any of the assets, users could manipulate utilization rate to points above 100%, effectively increasing interest rates to extremely high levels. We estimate that around 5%-10% of funds deposited in the Ethereum markets were at risk, while markets on Arbitrum remained immune given that all markets had deposits.
Within a few hours of the report, the core team attributed the cause of the vulnerability to the interest rate model contract (IRMv1) and concluded that depositing liquidity into the at-risk markets would ensure an attack of the reported nature was unprofitable to carry out. Following this conclusion, liquidity was deployed to some markets.
By May 1, the team had coded, tested and deployed a new interest rate model contract (IRMv2) that fixed the vulnerability.
On May 2, IRMv2 was applied to all silos on Arbitrum (see transactions under resources below.)
On Ethereum, given that the DAO owned functions controlling the interest rate model contract (IRMv1), we proposed the ownership transfer of certain smart contracts to a Safe controlled by the core team. The transfer of ownership was needed to allow the core team to deliver a fix immediately without making the attack vector public during the proposal voting duration and queuing (5 days total).
The governance proposal was successfully executed on May 7, giving the core team admin functions to migrate all silos to use the new IRMv2.
With control, IRMv2 was deployed and applied to all silos on Ethereum (see transactions under resources below).
The core team performed several safety checks and confirmed that markets are now all functioning properly.
On May 10, the Silo team asked the Certora team to review the shipped code (IRMv2) and ensure that it fully fixed the vulnerability.
On May 24, the Certora team sent us the following report:

We’ve successfully created a rule (interestNotMoreThenMax) for the interestRateModel that proves that the interest amount can't be higher than the max limit, meaning that the bug fix covers the exploited scenario.
We’ve fixed the current rules to match the updated code as well.
To our understanding, the fix indeed prevents the attack scenarios. The proposed fix keeps the interest rate safe and does not allow it to increase in an undesirable way. We could not find any other way to harm the protocol with the high utilization rate.

Details of Vulnerability

Background

Sending of ERC-20 tokens to a silo address — a regular ERC-20 transfer that does not trigger silo smart contract functions — caused the liquidity to increase in the market (silo). The transfer increases the liquidity that can be borrowed, however, it doesn’t not increase the totalDeposits or mint any share tokens - which is an expected protocol behavior.

However, in the now-deprecated InterestRateModel contract (IRMv1), the utilization ratio was calculated as the ratio of totalBorredAmount to totalDeposits. Borrowing the liquidity that is directly sent to the silo contract could cause the utilization ratio to be greater than 100%. As a result, when the utilization ratio became greater than 100%, the InterestRateModel model treated utilization as critical, causing the interest rate to rapidly soar to astronomical levels, consequently increasing the collateral value by multiple times. Interest that has not yet been repaid is also taken into account in collateral calculations.

The above conditions allowed collateral manipulations.

Attack example (POC)

Assuming the amount of ETH deposits in the wBTC silo is zero, an attacker deposits and mints 1e⁵ wei of WETH collateral tokens in the isolated market.
The attacker spends 1 ETH by sending it directly to the wBTC silo contract address.
Using another wallet, the attacker makes a wBTC deposit that is enough to borrow the donated 1 ETH.
In the next block, after 10 seconds, due to totalBorrowedAmount being extremely higher than totalDeposits, >5000 ETH of interest gets accrued. This makes 1e⁵ of collateralTokens associated with WETH that the attacker initially deposited worth >5000 ETH.
Then attacker borrows 150,000 worth of XAI because the protocol values the attacker’s collateral as ~5000 ETH while he only spent ~ 1ETH.

Description of the vulnerability fix

With the interest rate model contract (IRMv1) being the source of the vulnerability, the team made one main code change that changed the utilization ratio formula such that utilization ratio cannot exceed 100%. With the change in effect, even when the utilization ratio remains at maximum 100% for a significant period of time, the protocol functions as expected.

Along with changing the utilization ratio formula, we capped the interest rate at 10,000% per year. In addition, we adjusted the interest rate model configs to reduce the speed of interest rate growth in critical utilization regions. As a result, when the interest rate reaches the cap, the state of the model resets, causing the interest rate to drop from 10,000% per year to ~100% per year, allowing the isolated market to recover.

With these changes, the attack vector is not possible anymore. Borrowing the liquidity that is simply sent (donated) to a silo becomes pointless, because now it never forces the utilization ratio to increase above 100%.

All changes are shipped in a new interest rate model contact dubbed as IRMv2.

Breakdown of Changes

1. Utilization ratio calculations fix, 100% is a limit in InterestRateModel contract

Limiting the maximum utilization ratio to 100% allows the market to perform better interest rate computations without impacting any other part of protocol.

2. Limit for rcur - RCUR_CAP (FE/integrations, does not affect core protocol)

This is the limit for the current interest rate. We picked 10,000% of interest per year. The interest rate model works normally with a capped maximum value.

The protocol doesn’t read the current interest rate of a certain token asset but rather uses the compounded interest since last update. However, the interest rate is used in the UI and external protocol integrations (for example, investing strategies).

3. Limit for rcomp := RCOMP_CAP * _l.T.4. If we get a limit for rcomp, we reset Tcrit and Ri model parameters to zeros

Resetting parameters will make interest rate drop from 10,000% per year to 100% per year, at which point it will start growing again. Resetting parameters to zero give the market a chance to recover its state organically.

5. beta is divided by value of 4 for all IRM configs, except stableLowCap, stableHighCap and bridgeXAI

With current values of beta parameter, volatile assets will get their interest rate (proportional term) multiplied by 2 in one hour. Division of beta coefficient by 4 will result in changing time to increase from one hour to four hours, which will make the interest rate model behavior less aggressive.

If we forget about the integral term (which will have less impact in first hours of a critical utilization state), the proportional term will grow linearly. It will double in the first 4 hours, triple in 8, quadruple in 12, etc.