Althea Liquid Infrastructure - KmanOfficial's results

Liquid Infrastructure.

General Information

Platform: Code4rena

Start Date: 13/02/2024

Pot Size: $24,500 USDC

Total HM: 5

Participants: 84

Period: 6 days

Judge: 0xA5DF

Id: 331

League: ETH

Althea

Findings Distribution

Researcher Performance

Rank: 60/84

Findings: 1

Award: $25.73

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

25.7286 USDC - $25.73

Labels

bug
2 (Med Risk)
downgraded by judge
satisfactory
duplicate-87

External Links

Lines of code

https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L198-L237 https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L441-L445

Vulnerability details

Impact

During a distribution, whenever the distribute() is called the distributableERC20s array is accessed and the addresses are read from here in order to perform the required distributions per approved holder. If the distributableERC20s array values were to change at any time during the current distribution, the distribute() function may perform inaccurate distributions upon the newly assigned distributableERC20s array, unexpected transfers of various tokens or even result in failed transfers bricking the distribute() function.

Proof of Concept

Initially distributableERC20s has only 3 ERC20s to distribute amongst. For example USDT, USDC, ETH.

  • distribute(50) is called, and distribution commences (lock in place) - 100 eligible wallets. Transaction done in batches of 50.

  • First 50 with distribute() is called.

  • Admin/owner changes distributableERC20s using setDistributableERC20s() to TUSD, ETH, USDC.

  • distribute(100) is called again for the last 50 wallets - either transfers the incorrect distributions for the wrong ERC20 tokens to those wallets or fails due to insufficient balance within the contract.

Tools Used

Manual Code Review, VS Code

In order to mitigate this risk, there is two suggestions:

  1. Upon starting a new distribution round/lock, store a copy of the distributionERC20s array valid for the current distribution which can be removed from storage after it has ended. This copy would be referenced to throughout the current distribution.

  2. Only allow the distributableERC20s array to be modified only when there is no distribution currently taking place (when !LockedForDistribution).

Assessed type

Token-Transfer

#0 - c4-pre-sort

2024-02-22T06:06:44Z

0xRobocop marked the issue as duplicate of #260

#1 - c4-judge

2024-03-04T15:33:06Z

0xA5DF marked the issue as satisfactory

#2 - c4-judge

2024-03-08T15:13:03Z

0xA5DF changed the severity to 3 (High Risk)

#3 - c4-judge

2024-03-08T15:26:19Z

0xA5DF changed the severity to 2 (Med Risk)

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