Let’s Talk ENS Migration (Post-Mortem)

A deeper dive into CVE-2020–5232 and how we handled it.

Dean Eigenmann
Mar 3, 2020 · 4 min read

As you probably know by now, the ENS registry was recently migrated from the old LLL contract to a newer Solidity contract. The reason was a bug we have not yet made public found by the one and only samczsun. This post will give more details of how the ENS team handled the situation.

On November 8th, the night before Nick Johnson’s wedding, we were forwarded an email from Martin Holst Swende that was submitted to the Ethereum bug bounty program.

For those less technical, what this essentially boils down to is: if I set up my ENS name in a certain way, and transfer the ownership to someone else, I could later get the ownership back. This would be pretty bad, so we realized relatively quickly that we had to migrate our entire infrastructure to a new registry — something that is easier said than done, considering that the ENS registry was the one component designed not to be migrated.

We immediately started investigating the scope. At the time of investigation there were roughly 310,000 registered .ETH names. Each of which would require updating. Additionally there were roughly 50,000 subdomains, .XYZ names, .addr.reverse, etc, which would all also require updating. There were at least 60,000 names which use a resolver, each of which would need to be updated. Finally there were at least 37,000 names with addresses set, all of which would need updating.

Accounting for what needs to get updated, we’d be modifying roughly 847k storage slots. Which would result in 16,940 Mgas, or at 1 Gwei and $180/ETH, around 17 ETH or $3,049 in migration costs, before overhead. In the end however it cost us roughly 140 ETH or a total migration cost of $25,200 at $180/ETH.

So no easy operation. Let’s dive a bit deeper into the scope.

Names

Names who are registered by externally owned accounts could be migrated automatically. However we identified roughly 874 names owned by 241 distinct accounts which could be problematic. These were:

  1. Those that have had their registrant set to an inaccessible address (eg, 0xdead or 0x1)
  2. Those whose registrant is a contract

Of these most names were owned by a cold storage address, or accounts that have never sent a transaction but seem completely valid. 198 of the names however were owned by a contract, we were able to verify that with the exception of the subdomain registrar all were some form of multisig or DAO contract with an upgrade or transfer mechanism, or the ability to send arbitrary transactions. However, 16 of the names were set to an inaccessible address (0xdead, 0x1, or the base registrar address). Each of these either had the controller set to an externally owned account (and thus able to handle a migration) or to an inaccessible address.

Contracts

Thanks to the help of Martin Holst Swende, we compiled a list of all the smart contracts which may need upgrading. These were contracts that either have the ENS address stored in the contract code or in their storage. The list contained ~6k contracts.

Repositories

Additionally, we identified a large amount of repositories that reference the ENS contracts somewhere in their code. We would need to write a bot later to automatically upgrade these.

Timeline

Upon investigating the vulnerability further, we were able to say with a large certainty that the vulnerability was not exploited. Therefore we were able to give ourselves a reasonable timeline to work with.

On the 27th of January we would deploy a new ENS contract. The new ENS contract is written in solidity and contains a fallback to the previous ENS registry. Additionally we would already inform trusted teams of the vulnerability with an actual technical report so they could recognize the severity.

January 29th was when we would announce the vulnerability publicly and lay out the migration plan. We deployed the new ENS contracts, informed the ENS multisig key holders, and published technical guides on our documentation as well as articles on our public channels. Additionally we registered a CVE number and pushed those automatically using Github’s security advisors. This would automatically inform anyone using our code. We would also run a bot to create pull requests updating ENS addresses in Github repositories.

On the 3rd of February the migration process would be initiated and the old registry would be deactivated. This required the ENS key holders to sign multiple transactions for the upgrade process, Nick then also ran and monitored a script over several hours to migrate all the names we could automatically. The migration process would end on the 10th of February.

Hopefully this post provided you with a bit of insight on what was required to upgrade ENS. You can view the fully detailed report which we wrote internally here.

The Ethereum Name Service

News about the Ethereum Name Service (ENS).

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store