Kelp DAO | rsETH - Amithuddar'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: 170/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-69
Q-47

External Links

Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/utils/UtilLib.sol#L12

Vulnerability details

Impact

If a smart contract accepts an invalid address without proper validation, it can lead to various issues and vulnerabilities. Here are some potential consequences:

Loss of Funds: If the contract involves financial transactions and doesn't properly validate addresses, funds could be sent to an address that is not controlled by any user. This would result in a loss of funds with no way to recover them.

Functionality Issues: Accepting invalid addresses might lead to unexpected behavior or errors in the contract's logic. This could impact the overall functionality of the smart contract.

Security Vulnerabilities: Allowing invalid addresses could introduce security vulnerabilities, making it easier for attackers to exploit the contract. For example, an attacker might use an invalid address to manipulate the contract's state or disrupt its normal operation.

Reentrancy Attacks: If the invalid address is used as part of a callback mechanism or interacts with other contracts, it might open the door to reentrancy attacks.

Proof of Concept

The code if (address_ == address(0)) in Solidity is checking whether the variable address_ is equal to the Ethereum address 0x0000000000000000000000000000000000000000, which represents the null address or zero address.

This check is commonly used to determine whether an address has been set or initialized. However, it's important to note that it doesn't guarantee that the address is valid or that it corresponds to a deployed contract. It only checks if the address is the zero address.

If you want to check whether an address is valid and corresponds to a deployed contract, you may want to use additional checks, such as checking the bytecode size at the given address. For example:

if (address_ == address(0)) { // Address not set } else { uint size; assembly { size := extcodesize(address_) } if (size > 0) { // Address corresponds to a deployed contract } else { // Address is not the zero address, but it is not a deployed contract } }

Assessed type

Other

#0 - c4-pre-sort

2023-11-16T19:42:41Z

raymondfam marked the issue as insufficient quality report

#1 - c4-pre-sort

2023-11-16T19:43:02Z

raymondfam marked the issue as duplicate of #69

#2 - c4-judge

2023-11-29T20:58:12Z

fatherGoose1 changed the severity to QA (Quality Assurance)

#3 - c4-judge

2023-11-29T21:02:47Z

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