New ENS App Bug Bash!

🌱 ENS Ecosystem Bug Bounty
1

Starting today, we’re excited to begin the community bug bash for the new ENS app with name wrapper support!

The app is already live on the Goerli network, so put your bug bashing skills to the test until March 9th (2023-03-03T08:00:00Z→2023-03-09T08:00:00Z). We have a reward pool of 10 ETH up for grabs, making it a great opportunity to win some eth while helping us improve the new app.

Here’s a quick video explaining how to get setup on the Goerli network and start reporting bugs

How to participate:

  1. Go to https://alpha.ens.domains
  2. Connect with your wallet and switch to Goerli
  3. Start bug bashing! On the right of the screen is an orange feedback button, click this to open the feedback form and submit any issues you find

Don’t have any Goerli ETH? No problem! A Goerli faucet is provided on the homepage for any addresses that hold an ENS name on mainnet. Just connect with a wallet that has a mainnet ENS name and follow the prompts.

Good luck and happy bug bashing!

11 Likes
2

If you want to include pictures in your feedback, then you will need to upload your pictures to a separate hosting site like imgur.

Then include the image link in your feedback response!

3 Likes
3

What is the scope of this ‘bug bash’? Are you seeking smart contract interaction only or does this include 100% use of pentesting tools?

4

Can submit security issues too

5

I want to officially request a pause on this course of action.

I understand that everyone who has had their hand in this particular project is ready to get this product delivered to the the ENS community and the greater cryptocurrency ecosystem. I am aware that there has been a lot of pressure from the community to deploy these contracts.

A ‘bug bash’ that is open to the public to test for vulnerabilities is a good thing and I am all for it 100%.

Please take no offense. The video is great but we should provide more direction to the community. This, as of now is an open invite and dare to any hacker of all hats to attack all official components of ENS to include but not limited to ens.domains web host, subdomains, it’s directory, files, or subsequently any link the data a crawler can find at any depth, etc. We should caution this as implications of a trigger happy hacker could disrupt the normal everyday operation of the live systems. We do not want that to happen.

There needs to be a clear outline that provides explicit guidance in a bug bash ‘event’. There is no scope or context about what is within the bounds of any testing by a user, tool or third party service.

//Define the scope of the bug bash The scope of the bug bash should be clearly defined to specify which parts of the web application and contracts are within the bug bash’s scope and which are not. This helps to avoid misunderstandings between ENS Labs, ENS DAO, the person(s) reviewing and the participants

//Set the rules and guidelines: The rules and guidelines establish the framework for the bug bash, including the rewards system, submission protocol, and a timeline. This helps to ensure that participants understand the parameters and expectations.It is important to for participants to not over extend their work by doing unnecessary tasks that may or may not help the overall outcome.

//Provide feedback to participants about their submissions: It is important to provide timely and comprehensive feedback to bug bashers on the status of their submissions, including whether their submission is eligible, accepted, rejected, or needs further clarification.

//Fix bugs : Once bugs have been identified, they must be fixed by updating smart contracts, amending web application code, or securing any underlying infrastructure.

//Distribute rewards to eligible participoants Once bugs have been fixed, rewards should be distributed to the submitters who identified them, which incentivizes talented individuals to return when development warrants the need

After all is said and done, the deploying teamshould convene and learn from the process to identify areas for improvement in future bug bashes. The bug bash process should be reviewed to identify areas of improvement, increasing or decreasing the scope, evaluating the fairness of rewards or providing more comprehensive feedback to those who participate.

6

Some UI issues and also now getting an error saying one of my domains is too long…please see below.

EthMojiCheckPepe = Overlapping Boxes and confusing UI when selecting domains from the drop down lists…

image
image1170×2532 343 KB

Unable to mint an EthMojiPunk on alpha app due to being too long?…However I am able to and have minted many already on the existing app. On main net, please see the 1st image is already minted on Main net and the second image is from alpha after I copy and pasted the domain in to search:

image
image1170×2532 453 KB

image
image1170×2532 172 KB

7

Hey, we don’t really want to provide too much guidance on what to test or how it should be tested. We have done a lot of internal testing and part of the problem is we will tend to click through the app in ways that a new user might not. So we believe it is really important to just let people use the app and see what issues they run into. What I had in mind is just a user manually clicking through the app, but we are open to other kinds of submissions.

I’m not sure why the bug bash in particular is opening the door to hackers and attacks, the door is always open to them.

We will be actively fixing bugs as they come in, not before confirming they existed so that a reward can be given out if appropriate. We have had 100s of submissions already so it isn’t practical for us to give feedback on every single submission.

Having said all that appreciate the feedback.

2 Likes
8

This was something previously discussed with regards to the Name Wrapper.

Only labels that are 255 bytes or less (not characters, bytes, UTF-8) are allowed in the wrapper. Since the new manager UI will use the new registrar controller which goes through the wrapper, you will not be able to register any such name through the new UI. You will not be able to wrap any existing name with a long label like that either.

Each of those :cool: characters encode into four bytes with UTF-8 I believe. So you could only have 63 of those characters in a label. That name appears to have 389 of those emojis in it, so 1556 bytes, over 6 times the limit.

1 Like
9

Just in case you might have missed it, apart from the general bug bash we also have a few guidelines on the always active Bug Bounty Program here:

This is separate from the ENS App Bug Bash, but it does cover security vulnerabilities found and gives guidelines on how to report them.

1 Like
10

Adding a text record through the UI with either ’ or " in the name (not value) causes the application to crash.

image
image2232×1082 414 KB

1 Like
11

It’s not a bug, but small UX issue.

I think that the “Open Wallet” button should be on the right

image
image1158×910 68.9 KB

In multiple other confirmation boxes (eg renewal shown below) proceed is on the right and cancel/back is on the left.

image
image1294×1220 85.6 KB

2 Likes
12

German language only seems partially implemented. Most pages are just fully english

image
image2334×1164 90.1 KB

3 Likes
13

Thank you for the info and the link.

Will I be able to extend the EthMoji domains that I currently have minted?

And will I still be able to use the current existing site in order to mint new domains?

2 Likes
14

Yes.

I’m not sure on this, @Leon would know. Maybe once the new app is officially launched, the old one will be available for some time, or at least on IPFS.

The current ETH Registrar Controller contract will remain, so you will definitely still be able to mint those long names at the contract level.

1 Like
15

Not to sound snarky or as if I’m coming off as pretentious, disingenuous et. al. but this is raises concerns for me as an individual who wants to see the best possible out come for this project.

These are the most specific guidelines for this ’ bug bash’ (which can be interpreted in many ways) event.

-put your bug bashing skills to the test
-Start bug bashing!
-submit any issues you find
-Can submit security issues too

Reward and Scoring System

There is zero guidance published about an earnest bounty rewards system for the approximate $16,000-$18,000 of value in Ether that is up for grabs.

It’s said there are hundreds of submissions. How will the eligibility of a report be scored by a submitter? Is ENS just gonna wing it decide on who receives how much arbitrarily? Does that mean that anyone who submits gets rewarded? It’s likely that you will have to deal with people who believe they deserve a reward but for some reason did not. Some of those people might argue a really good case. Is there a limit to how many people will be rewarded?

Here is an app, find bugs. Mass adoption soon.

I’m serious appalled and even though I don’t have enough voting power or tenure to make any change but this is what is representing the look. I want to encourage DAO members to take a moment and thing about this and comparing to the rest of the industry.

Again, I’m not trying to stomp on any persons whites shoes but a top notch product deserves more, especially when it’s funded.

If my talking points are invalid, please tell me.

16

Sure if you are unhappy with the way the current bug bash is going I’m happy to continue the discussion.

For me at least it is unusual to do a public bug bash, and so since it is normally internal everyone knows the deal and this appears to have lead to inadequate communication, so apologies for that.

As the contracts have already had multiple audits, the main focus is to find bugs in the front-end app itself. As @cthulu.eth mentioned bugs that are ultimately traced to smart contracts will be covered by our always active bounty.

The plan is to give 1ETH to each winning issue. What we will be mainly looking for is the severity of the bug coupled with bugs that we feel would be less likely to be caught by us internally. Bugs that we are less likely to catch can include simple bugs that stem from actions that we are unlikely to have thought of doing so far, or they could include a complicated series of actions that we likewise would not have thought of doing. The quality of the submission itself is also important but generally as long as the issue is reproducible it won’t count in your favour beyond that.

In the case where multiple people submit the same bug then the person who found it first will get the reward.

Hope this helps!

2 Likes
17

i have finished; thanks for your share

1 Like
18

Thank you everyone for contributions to the ENS app bug bash! We’re ending submissions now (at 9 March 11:59PM PST8PDT) for possible entries to our bug bash prize pool.

We’ve had over 9000 entries, and we’re very thankful to have so much support from the community. The feedback button will remain, and we’d still appreciate any feedback even though the incentives have ended.

3 Likes
19

I returned to testing alpha and it seems like there have been a number of updates to the UI since the Bug Bash.

During the bug bash I registered a single ENS name and created a subdomain. When I logged in today the wallet I minted from is still listed as the Ethereum address. However, I noticed the owner and manager were no longer my mint wallet, it appears the owner and manager are the wrapper address.

I don’t think these are bugs, just questions:

  1. Is the only was to create a sub on alpha via the name wrapper (as opposed to the old method where owner/registrant of root maintains control)? I don’t remember and don’t show any tx where I wrapped the sub follow creation of the sub. In either case does the wrapper automatically become the owner & manager when wrapping a sub?

  2. If the wrapper becomes both owner and manager, then do/did I permanently lose control over the records of the root? I don’t think it’s a bug at all, just that I think most projects would want to retain control as manager. Is there anyway to regain the manager of the name currently owned/managed by the wrapper?

  3. “Timer” appears to be the new verbiage for commit. During the Bug Bash I submitted a commit for a 2nd name but failed to register it due to a error (judging by Twitter screenshots others had this same error) but when I returned today it seemed like the timer (commit) was still reserving the name for me - 24 days after the initial commit tx. Is there an expiration on the commit/timer and am I the only one that can register the name (that seems to be the language on the “timer page”?

1 Like
20

  1. You can create subnames on unwrapped names as well. When a name is wrapped, technically (from the perspective of the ENS registry / .eth registrar) the Name Wrapper contract is the owner. The NW issues that wrapped NFT to you in return. If you unwrap the name, then that wrapped NFT is burned, and you are returned control (Owner/Manager) over the name in the core ENS contracts.

  2. You are only seeing that because on Goerli, there have been multiple revisions to the Name Wrapper contract. So you wrapped your name in an earlier version. However the manager UI only recognizes the current latest revision. There is a guide on unwrapping from old revisions on Goerli here:

  1. When you perform the commit transaction, that is good for 7 days. But it does not reserve the name for you. If you have performed the commit but not the final register tx, then someone else can register the name before you. However, the commit transaction does not reveal what name you are registering, as it’s only a hash value on-chain. FYI none of this has changed with the new contracts, that’s how it currently works today as well. I agree that the current language “prevents others from registering this name before you do” can be misleading.
2 Likes