Venus Prime - ge6a's results

Earn, borrow & lend on the #1 Decentralized Money Market on the BNB chain.

General Information

Platform: Code4rena

Start Date: 28/09/2023

Pot Size: $36,500 USDC

Total HM: 5

Participants: 115

Period: 6 days

Judge: 0xDjango

Total Solo HM: 1

Id: 290

League: ETH

Venus Protocol

Findings Distribution

Researcher Performance

Rank: 78/115

Findings: 1

Award: $4.37

QA:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Lines of code

https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L872-L897 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L647-L664 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L623-L639 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L794-L802 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L200-L230 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L389-L392 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L607-L617 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L365-L382

Vulnerability details

Summary

Venus Prime uses the Cobb-Douglas function to determine how much of the available rewards each user with a Prime token should receive. This calculation relies on a user's score, which is based on their supply and borrow values for a specific token. The larger these values, the higher the score, but there are maximum limits for both. If these limits are exceeded, the upper boundary is used. The function _capitalForScore applies these limits and takes into account the prices of XVS and the underlying token, which can change due to market conditions. It turns out that users with the same supply and borrow values can have significantly different scores because of variations in token prices at the time of calculation. Additionally, users can update their scores to maximize rewards using one the functions xvsUpdated or accrueInterestAndUpdateScore. This behavior creates an unfair advantage and should not be possible.

Proof of Concept

First, it needs to be clarified when the score is recalculated and when the saved value is used. The function that calculates the score is _calculateScore.

https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L647-L664

It is called first when markets are initialized for a specific user and then only when there are changes in the user's balance. The functions that directly or indirectly update the saved values for the score are: _initializeMarkets, _updateScore, updateScores, accrueInterestAndUpdateScore, _accrueInterestAndUpdateScore, and xvsUpdated.

https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L623-L639 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L794-L802 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L200-L230 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L389-L392 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L607-L617 https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L365-L382

I won't describe in detail what each of them is used for, but it's important to see which of them can be called by the user without restrictions. These are accrueInterestAndUpdateScore and xvsUpdated, which are external and have no other limitations. Therefore, a user, when they decide that an appropriate moment has come, can call one of these functions and update their score.

Let's consider a possible scenario in the context of the _capitalForScore function.

https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/Prime.sol#L872-L897

We have two users, Alice and Bob, in the same market. Each of them has 1000 XVS and a supply of 1000 tokens. At the current moment, the price of XVS is $5, and the price of the underlying token is $10. The _capitalForScore function is executed for both users.

supplyCapUSD = 5 * 1000 = 5000 supplyUSD = 10 * 1000 = 10000 Since 10000 > 5000, the supply is calculated as 1000 * 5000 / 10000 = 500.

At this point, Alice and Bob have the same score. After some time, the price of the underlying token drops from $10 to $8. Alice sees an opportunity to increase her score and thereby receive a larger portion of the rewards fund. She calls one of the functions mentioned earlier and updates her score.

supplyCapUSD = 5 * 1000 = 5000 supplyUSD = 8 * 1000 = 8000 Since, 8000 > 5000, the supply is calculated as 1000 * 5000 / 8000 = 625.

At this point, Alice has a significantly higher score than Bob, even though they have the same assets and she could claim more rewards from the rewards fund.

Impact

Financial loss for legitimate users because their score is calculated at a wrong time. Financial gain for malicious users who exploit this behavior. About the severity i think that this issue is easy to exploit and very likely to happen.

Tools Used

Manual Review

2 ideas to mitigate it:

  • build some kind of protection for accrueInterestAndUpdateScore and xvsUpdated so that a malicious user can't call them. I should note that even if you add such protection a user may be able to trigger an update in another way using legitimate features of the Venus protocols.
  • periodically update the score of all users. The downside of this solution is that it could be costly.

Assessed type

Other

#0 - 0xRobocop

2023-10-04T22:50:23Z

Design Decision

#1 - c4-pre-sort

2023-10-04T22:50:27Z

0xRobocop marked the issue as low quality report

#2 - c4-pre-sort

2023-10-05T04:45:32Z

0xRobocop marked the issue as duplicate of #148

#3 - c4-judge

2023-11-01T02:49:33Z

fatherGoose1 changed the severity to QA (Quality Assurance)

#4 - c4-judge

2023-11-03T02:48:40Z

fatherGoose1 marked the issue as grade-b

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter