ENS contest - pashov's results

Decentralised naming for wallets, websites, & more.

General Information

Platform: Code4rena

Start Date: 12/07/2022

Pot Size: $75,000 USDC

Total HM: 16

Participants: 100

Period: 7 days

Judge: LSDan

Total Solo HM: 7

Id: 145

League: ETH

ENS

Findings Distribution

Researcher Performance

Rank: 71/100

Findings: 2

Award: $84.32

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

5.45 USDC - $5.45

Labels

bug
duplicate
2 (Med Risk)

External Links

Lines of code

https://github.com/code-423n4/2022-07-ens/blob/ff6e59b9415d0ead7daf31c2ed06e86d9061ae22/contracts/ethregistrar/ETHRegistrarController.sol#L183 https://github.com/code-423n4/2022-07-ens/blob/ff6e59b9415d0ead7daf31c2ed06e86d9061ae22/contracts/ethregistrar/ETHRegistrarController.sol#L204 https://github.com/code-423n4/2022-07-ens/blob/ff6e59b9415d0ead7daf31c2ed06e86d9061ae22/contracts/ethregistrar/ETHRegistrarController.sol#L211 https://github.com/code-423n4/2022-07-ens/blob/ff6e59b9415d0ead7daf31c2ed06e86d9061ae22/contracts/ethregistrar/BulkRenewal.sol#L67

Vulnerability details

Impact: The use of the deprecated transfer() function for an address will inevitably make the transaction fail when:

  1. The claimer smart contract does not implement a payable function.
  2. The claimer smart contract does implement a payable fallback which uses more than 2300 gas unit.
  3. The claimer smart contract implements a payable fallback function that needs less than 2300 gas units but is called through proxy, raising the call's gas usage above 2300.

Additionally, using higher than 2300 gas might be mandatory for some multisig wallets.

Recommended Mitigation Steps: Use **** call() instead of transfer()

#0 - jefflau

2022-07-22T09:51:25Z

Duplicate of #133

Lines of code

https://github.com/code-423n4/2022-07-ens/blob/ff6e59b9415d0ead7daf31c2ed06e86d9061ae22/contracts/dnssec-oracle/Owned.sol#L18 https://github.com/code-423n4/2022-07-ens/blob/ff6e59b9415d0ead7daf31c2ed06e86d9061ae22/contracts/root/Ownable.sol#L18

Vulnerability details

Proof of concept: The current ownership transfer pattern is calling transferOwnership() or setOwner() function with an address type argument, which is immediately set to the new owner of the contract. If the new address of the new owner is actually not a valid account then the ownership just got transferred to an uncontrolled account, breaking all functions that can be called only by owner.

Impact: this can impact availability of the protocol. Especially the problem in Ownable.sol, it can result in no way to withdraw funds from ETHRegistrarController

Recommended Mitigation Steps: Implement a two-step process where the owner nominates an account and the nominated account needs to call an acceptOwnership() function for the transfer of ownership to be completed. This ensures the nominated account is a valid & active one.

#0 - makoto

2022-07-27T10:39:51Z

#1 - dmvt

2022-08-04T23:39:55Z

Lack of 2 step ownership confirmation is considered a QA issue by consensus of the C4 judging body. Downgrading.

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