Revert Lend - Timenov's results

A lending protocol specifically designed for liquidity providers on Uniswap v3.

General Information

Platform: Code4rena

Start Date: 04/03/2024

Pot Size: $88,500 USDC

Total HM: 31

Participants: 105

Period: 11 days

Judge: ronnyx2017

Total Solo HM: 7

Id: 342

League: ETH

Revert

Findings Distribution

Researcher Performance

Rank: 31/105

Findings: 2

Award: $440.80

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: 0xjuan

Also found by: CaeraDenoir, Tigerfrake, Timenov, novamanbg, santiellena

Labels

bug
3 (High Risk)
satisfactory
sufficient quality report
upgraded by judge
duplicate-141

Awards

398.0218 USDC - $398.02

External Links

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/main/src/transformers/V3Utils.sol#L115-L352

Vulnerability details

Impact

In V3Utils::execute, users can Execute instruction by pulling approved NFT instead of direct safeTransferFrom call from owner. However there is no validation whether the caller is the owner of the tokenId or approved address.

Proof of Concept

As we can see in executeWithPermit, there is a validation:

        if (nonfungiblePositionManager.ownerOf(tokenId) != msg.sender) {
            revert Unauthorized();
        }

But there is no such check in execute or a check if the msg.sender is approved.

Consider the following scenario:

  1. User A approves nonfungiblePositionManager.
  2. User A calls execute with his instructions.
  3. User B sees the tx and frontruns User A, but with different instructions.

Tools Used

Manual Review

Add validation if the msg.sender is owner or approved.

Assessed type

Access Control

#0 - c4-pre-sort

2024-03-22T16:27:45Z

0xEVom marked the issue as duplicate of #141

#1 - c4-pre-sort

2024-03-22T16:27:50Z

0xEVom marked the issue as sufficient quality report

#2 - c4-judge

2024-04-01T06:44:40Z

jhsagd76 marked the issue as satisfactory

#3 - c4-judge

2024-04-01T15:42:48Z

jhsagd76 changed the severity to 3 (High Risk)

Awards

42.7786 USDC - $42.78

Labels

bug
downgraded by judge
grade-a
QA (Quality Assurance)
sufficient quality report
:robot:_17_group
duplicate-366
Q-38

External Links

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/transformers/LeverageTransformer.sol#L39-L40 https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/transformers/LeverageTransformer.sol#L122-L123

Vulnerability details

Impact

As per the comments of the functions leverageUp and leverageDown in LeverageTransformer.sol, these functions are supposed to be called by the transform function in the Vault. However there is no such protection and anyone can call them.

Proof of Concept

As there is no access control, a malicious user can craft a smart contract that will use for his needs.

First lets look at what the attacker can configure leverageUp function.

  1. The token will be IVault(msg.sender).asset()
  2. Function call IVault(msg.sender).borrow(params.tokenId, amount)

Now lets look at leverageDown.

  1. Token will be IVault(msg.sender).asset()
  2. Token approve SafeERC20.safeApprove(IERC20(token), msg.sender, amount)
  3. Function call IVault(msg.sender).repay(params.tokenId, amount, false)

Tools Used

Manual Review

Add state variable of type address vault, set the value in the constructor, add validation require(msg.sender == vault, "only vault.");. Also function updateVault can be created in order to change the address in the future. Do not forget to add onlyOwner modifier to that function.

Assessed type

Access Control

#0 - c4-pre-sort

2024-03-16T10:09:50Z

0xEVom marked the issue as duplicate of #366

#1 - c4-pre-sort

2024-03-18T09:24:11Z

0xEVom marked the issue as sufficient quality report

#2 - c4-judge

2024-03-29T01:44:21Z

jhsagd76 changed the severity to QA (Quality Assurance)

#3 - c4-judge

2024-03-29T01:45:29Z

jhsagd76 marked the issue as grade-a

#4 - jhsagd76

2024-03-29T01:45:31Z

L-A

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