Foundation contest - kirk-baird's results

Building the new creative economy

General Information

Platform: Code4rena

Start Date: 24/02/2022

Pot Size: $75,000 USDC

Total HM: 21

Participants: 28

Period: 7 days

Judge: alcueca

Total Solo HM: 15

Id: 94

League: ETH

Foundation

Findings Distribution

Researcher Performance

Rank: 28/28

Findings: 1

Award: $181.02

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

Awards

181.0202 USDC - $181.02

Labels

bug
QA (Quality Assurance)

External Links

Lines of code

https://github.com/code-423n4/2022-02-foundation/blob/main/contracts/FETH.sol#L232-L242

Vulnerability details

Impact

The function depositFor(address account) allows account to be zero. If a user / program accidentally sets this value to be zero then the msg.value will be added to accountToInfo[address(0)] and the funds will not be recoverable.

Proof of Concept

function depositFor(address account) public payable { if (msg.value == 0) { revert FETH_Must_Deposit_Non_Zero_Amount(); } AccountInfo storage accountInfo = accountToInfo[account]; // ETH value cannot realistically overflow 96 bits. unchecked { accountInfo.freedBalance += uint96(msg.value); } emit Transfer(address(0), account, msg.value); }

Consider adding a check to ensure account is non zero to prevent accidental loss of funds.

For example

function depositFor(address account) public payable { if (account == address(0)) { revert FETH_Must_Deposit_Non_Zero_Account(); } ...

#0 - HardlyDifficult

2022-02-25T19:44:37Z

Duplicate of #2

This is a great suggestion to help avoid user error, and we have PR'd the recommended change.

We believe the original reported severity of 1 (Low Risk) is a better fit for this issue. There is no risk to the protocol or other users here. The concern is about users making a mistake that prevents them from accessing their own funds.

#1 - alcueca

2022-03-16T10:42:41Z

Agree with the downgraded severity.

#2 - alcueca

2022-03-17T09:59:28Z

QA Report score: 10

#3 - alcueca

2022-03-18T10:53:49Z

Removing the duplicate because it doesn't apply to QA Reports

#4 - CloudEllie

2022-03-24T19:03:21Z

Since this issue was downgraded to a QA level, and the warden did not submit a separate QA report, we've renamed this one to "QA report" for consistency.

The original title, for the record, was "depositFor() Does Not Verify account is Non Zero Potentially Losing Funds."

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