Kelp DAO | rsETH - seerether's results

A collective DAO designed to unlock liquidity, DeFi and higher rewards for restaked assets through liquid restaking.

General Information

Platform: Code4rena

Start Date: 10/11/2023

Pot Size: $28,000 USDC

Total HM: 5

Participants: 185

Period: 5 days

Judge: 0xDjango

Id: 305

League: ETH

Kelp DAO

Findings Distribution

Researcher Performance

Rank: 164/185

Findings: 1

Award: $2.76

QA:
grade-b

🌟 Selected for report: 0

šŸš€ Solo Findings: 0

Awards

2.7592 USDC - $2.76

Labels

bug
downgraded by judge
grade-b
insufficient quality report
QA (Quality Assurance)
duplicate-70
Q-65

External Links

Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/NodeDelegator.sol#L45

Vulnerability details

Impact

• Funds at risk: All tokens approved to the external contract could potentially be drained by a malicious contract. This puts user funds at risk of theft. The severity is high: • Critical severity: This approve-max pattern undermines the security model of ERC20 approvals. It gives unlimited access to external contracts, which is a critical security risk.

Proof of Concept

Approving the maximum amount of an ERC20 token to transfer could potentially be dangerous and lead to token theft. Here is a more detailed explanation: The key issue is in this code:

IERC20(asset).approve(eigenlayerStrategyManagerAddress, type(uint256).max);

This approves the EigenStrategyManager contract to transfer the maximum possible amount of the ERC20 token. The approve() function on ERC20 tokens allows a spender (in this case the EigenStrategyManager) to transfer up to a specified amount from the caller's account. By approving the maximum uint256 amount, it gives the EigenStrategyManager contract full control to transfer any and all of that token from the NodeDelegator's balance. This could be exploited by a malicious EigenStrategyManager contract that drains all the approved tokens into another account. Or if the EigenStrategyManager contract itself is compromised with a vulnerability, an attacker could drain the tokens

In summary, approving the maximum amount gives too much power to the spender contract and could lead to theft.

Tools Used

Manual

Only approve the exact amount needed for the deposit:

uint256 depositAmount = IERC20(asset).balanceOf(address(this)); IERC20(asset).approve(eigenlayerStrategyManagerAddress, depositAmount );

This restricts the approval to only the amount being deposited. Additionally, you could add a call to approve(0) after the deposit to fully revoke the approval:

IERC20(asset).approve(eigenlayerStrategyManagerAddress, 0);

This prevents any potential issues if the full approval amount was not used.

Assessed type

Other

#0 - c4-pre-sort

2023-11-16T07:05:28Z

raymondfam marked the issue as insufficient quality report

#1 - c4-pre-sort

2023-11-16T07:05:36Z

raymondfam marked the issue as duplicate of #70

#2 - c4-judge

2023-11-29T19:28:16Z

fatherGoose1 changed the severity to QA (Quality Assurance)

#3 - c4-judge

2023-11-29T19:29:10Z

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