ENS Permanent Registrar

1 Update [2019-05-29]

In addition to the results below, ConsenSys Diligence also audited an updated Root contract with the SHA1 hash 42d807dc438b978b7ddfd7a0c030cf6140bd49d6.

No new issues were found.

2 Summary

ConsenSys Diligence conducted a security audit on two new components of the Ethereum Name Service (ENS): the .eth Permanent Registrar and the new ENS Root.

• .eth Permanent Registrar is a new rent-based registrar for the .eth top-level domain.
• New ENS Root is to allow for certain onlyOwner functions to be disintermediated from the ENS root key holders. The main new functionality is the ability for anyone to register a new TLD based on DNSSEC records.

2.1 Audit Goals

The focus of the audit was to verify that the smart contract system is secure, resilient and working according to its specifications. The audit activities can be grouped in the following three categories:

Security: Identifying security related issues within each contract and within the system of contracts.

Sound Architecture: Evaluation of the architecture of this system through the lens of established smart contract best practices and general software best practices.

Code Correctness and Quality: A full review of the contract source code. The primary areas of focus include:

• Correctness
• Readability
• Sections of code with high complexity
• Improving scalability
• Quantity and quality of test coverage

2.2 System Overview

Documentation

The following documentation was available to the audit team:

• This Documentation with description about the mechanism of the .eth Permanent Registrar and ETHRegistrarController.

Scope

The audit focus was on the smart contract files, and test suites found in the following repositories of the ensdomains GitHub organization:

Specifically, the following files were audited:

• BaseRegistrar.sol
• BaseRegistrarImplementation.sol
• ETHRegistrarController.sol
• Ownable.sol
• PriceOracle.sol
• Root.sol
• SafeMath.sol
• SimplePriceOracle.sol
• StablePriceOracle.sol
• StringUtils.sol

There are other components of the pending ENS upgrade that were not part of this audit. Notably, the DNSSEC oracle and DNSSEC-based registrar were out of scope and not considered during this audit.

Architecture

ENS has two principal components: the registry, and resolvers. The system is broadly analogous to DNS.

The ENS registry is a simple smart contract that tracks for each registered name: who owns it, where the name can be resolved, and how long a client may cache name resolution. Resolvers (EIP-137) are responsible for actually translating names into addresses.

A registrar is a contract responsible for allocating subdomains and updating records in the ENS registry. Registrars can be configured at any level of ENS, and they are pointed to by the owner field of the registry.

There exists an auction-based interim .eth registrar which will be replaced by the new permanent .eth registrar (BaseRegistrarImplementation). The new registrar implements an ERC721-compatible non-fungible token. Users can interact directly with the non-fungible token to transfer ownership. To obtain an available subdomain or renew subdomain ownership, users interact with any number of controllers connected to the registrar. At the time of this audit, only one controller exists: the ETHRegistrarController. This controller handles domain names that are at least 7 characters long and uses a simple rent-based model similar to .com domain ownership in DNS. It uses a price oracle (StablePriceOracle) to control rent prices in US dollars and convert those prices to ETH.

A new Root contract is being introduced that maps TLDs to registrars. It points the .eth TLD at the BaseRegistrarImplementation, and it points all others at a registrar specified in DNSSEC records for the TLD or a generic DNSSEC-based registrar as a fallback. This allows DNS owners to dictate how ENS names are resolved for their DNS.

The ENS system itself is controlled by a multisig wallet with key stakeholders from the Ethereum community. They have broad control over the system, up to and including replacing the entire registrar implementation. As such, ENS is only trusted to the extent that these key stakeholders are trusted.

2.3 Key Observations/Recommendations

• The system is well designed. The old registrar does proper checks to be disabled when the new system is deployed.
• The code is well written and considers most of the security best practices.
• Avoid inline assembly: A great deal of complexity is added by using libraries with inline assembly code. Wherever possible, we recommend avoiding inline assembly in favor of more straightforward Solidity-based implementations.
• Insufficient test coverage: Test code coverage is likely high, but there’s a lot of room for improvement. See section 6 for more details.

3 Issues

Each issue has an assigned severity:

• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Critical issues are directly exploitable security vulnerabilities that need to be fixed.

/**
* @dev Initializes a buffer with an initial capacity.
* @param buf The buffer to initialize.
* @param capacity The number of bytes of space to allocate the buffer.
* @return The buffer, for chaining.
*/
function init(buffer memory buf, uint capacity) internal pure returns(buffer memory) {
    if (capacity % 32 != 0) {
        capacity += 32 - (capacity % 32);
    }
    // Allocate space for the buffer data
    buf.capacity = capacity;
    assembly {
        let ptr := mload(0x40)
        mstore(buf, ptr)
        mstore(ptr, 0)
        mstore(0x40, add(32, add(ptr, capacity)))
    }
    return buf;
}

contract Test {
    using Buffer for Buffer.buffer;

    function test() external pure {
        Buffer.buffer memory buffer;
        buffer.init(1);

        // foo immediately follows buffer.buf in memory
        bytes memory foo = new bytes(0);
       
        assert(foo.length == 0);

        buffer.append("A");

        // "A" == 65, gets written to the high order byte of foo.length
        assert(foo.length == 65 * 256**31);
    }
}

mstore(0x40, add(ptr, add(capacity, 32)))

function price(string calldata /*name*/, uint /*expires*/, uint duration) external view returns(uint) {
    return duration * rentPrice;
}

function makeCommitment(
    string memory name,
    address owner, /* or perhaps committer/sender */
    bytes32 secret
)
    pure
    public
    returns(bytes32)
{
    bytes32 label = keccak256(bytes(name));
    return keccak256(abi.encodePacked(label, owner, secret));
}

function write(buffer memory buf, uint off, bytes memory data, uint len) internal pure returns(buffer memory) {
    require(len <= data.length);

    if (off + len > buf.capacity) {
        resize(buf, max(buf.capacity, len + off) * 2);

function write(buffer memory buf, uint off, bytes32 data, uint len) private pure returns(buffer memory) {
    if (len + off > buf.capacity) {
        resize(buf, (len + off) * 2);
    }

function readUint8(bytes memory self, uint idx) internal pure returns (uint8 ret) {
    require(idx + 1 <= self.length);
    assembly {
        ret := and(mload(add(add(self, 1), idx)), 0xFF)
    }
}

function readUint8(bytes memory self, uint idx) internal pure returns (uint8 ret) {
    return uint8(self[idx]);
}

require(_transferPeriodEnds > now + 183 days);

function price(string calldata name, uint /*expires*/, uint duration) view external returns(uint) {
    uint len = name.strlen();
    require(len > 0);
    if(len > rentPrices.length) {
        len = rentPrices.length;
    }
    uint priceUSD = rentPrices[len - 1].mul(duration);

function register(string calldata name, address owner, uint duration, bytes32 secret) external payable {
    // Require a valid commitment
    bytes32 commitment = makeCommitment(name, secret);
    require(commitments[commitment] + MIN_COMMITMENT_AGE <= now);

    // If the commitment is too old, or the name is registered, stop
    if(commitments[commitment] + MAX_COMMITMENT_AGE < now || !available(name))  {
        msg.sender.transfer(msg.value);
        return;

function strlen(string memory s) internal pure returns (uint256) {
    uint256 i = 0;
    uint256 len;
    for (len = 0; i < bytes(s).length; len++) {
        byte b = bytes(s)[i];
        if (b < 0x80) {
            i += 1;
        } else if (b < 0xE0) {
            i += 2;
        }
        ...
    }
   
    return len;
}

4 Threat Model

The creation of a threat model is beneficial when building smart contract systems as it helps to understand the potential security threats, assess risk, and identify appropriate mitigation strategies. This is especially useful during the design and development of a contract system as it allows to create a more resilient design which is more difficult to change post-development.

A threat model was created during the audit process in order to analyze the attack surface of the contract system and to focus review and testing efforts on key areas that a malicious actor would likely also attack. It consists of two parts: a high-level analysis that help to understand the attack surface and a list of threats that exist for the contract system.

4.1 Overview

The following assets are managed by contracts and likely targets for an attacker:

• Registered domain names (e.g. foo.eth)
• Ether, in the form of rent paid to the ETHRegistrarController

The following actors have access to the system to perform an attack:

• System owners (ENS itself, registrars, controllers, price oracles)
• DNS domain/subdomain owners, who can update DNSSEC records
• Users who are registering, renewing, and transferring domains

The following describes the surface area available to attackers:

• DNSSEC records
• Registrars and controllers
• Root contract
• Ethereum private keys

Because they were out of scope for this audit, we did not consider some interesting targets such as the DNSSEC oracle, DNSSEC-based registrar, the interim .eth registrar, or the multisig wallet used for ENS ownership.

4.2 Threat Analysis

The following table contains a list of identified threats, along with their mitigations:

5 Tool-based analysis

The issues from the tool based analysis have been reviewed and the relevant issues have been listed in chapter 3 - Issues.

5.1 MythX

MythX is a security analysis API for Ethereum smart contracts. It performs multiple types of analysis, including fuzzing and symbolic execution, to detect many common vulnerability types. The tool was used for automated vulnerability discovery for all audited contracts and libraries. More details on MythX can be found at mythx.io.

Where possible, we ran the full MythX analysis. MythX is still in beta, and where analysis failed, we fell back to running Mythril Classic, a large subset of the functionality of MythX.

Below is the raw output of MythX and Mythril Classic vulnerability scans:

In order to run MythX, Root.sol contract was flattened. flat_root.sol line numbers reflect on the output of truffle-flattener contracts/Root.sol.

Title: Floating Pragma
Head: A floating pragma is set.
Description: It is recommended to make a conscious choice on what version of Solidity is used for compilation. Currently any version equal or greater than "0.4.24" is allowed.
Source code:

flat_root.sol 1:0
--------------------------------------------------
pragma solidity ^0.4.24;
--------------------------------------------------

==================================================
 Title: Shadowing State Variables
Head: State variable shadows another state variable.
Description: The state variable "CLASS_INET" in contract "DNSClaimChecker" shadows another state variable with the same name "CLASS_INET" in contract "Root".
Source code:

flat_root.sol 869:4
--------------------------------------------------
uint16 constant CLASS_INET = 1
--------------------------------------------------

==================================================
 Title: Shadowing State Variables
Head: State variable shadows another state variable.
Description: The state variable "TYPE_TXT" in contract "DNSClaimChecker" shadows another state variable with the same name "TYPE_TXT" in contract "Root".
Source code:

flat_root.sol 870:4
--------------------------------------------------
uint16 constant TYPE_TXT = 16
--------------------------------------------------

==================================================
 Title: Shadowing State Variables
Head: Local variable shadows a state variable.
Description: The local variable "owner" in contract "ENS" shadows the state variable with the same name "owner" in contract "Ownable".
Source code:

flat_root.sol 20:58
--------------------------------------------------
address owner
--------------------------------------------------
flat_root.sol 22:36
--------------------------------------------------
address owner
--------------------------------------------------

==================================================
 Title: Shadowing State Variables
Head: Local variable shadows a state variable.
Description: The local variable "owner" in contract "Root" shadows the state variable with the same name "owner" in contract "Ownable".
Source code:

flat_root.sol 1012:44
--------------------------------------------------
address owner
--------------------------------------------------
flat_root.sol 1037:36
--------------------------------------------------
address owner
--------------------------------------------------

==================================================
 Title: Shadowing State Variables
Head: Local variable shadows a state variable.
Description: The local variable "oracle" in contract "DNSClaimChecker" shadows the state variable with the same name "oracle" in contract "Root".
Source code:

flat_root.sol 881:29
--------------------------------------------------
DNSSEC oracle
--------------------------------------------------

==================================================

BaseRegistrarImplementation

Mythril Classic results for BaseRegistrarImplementation are as follows. flat_BaseRegistrarImplementation.sol line numbers reflect on the output of truffle-flattener contracts/BaseRegistrarImplementation.sol

SWC ID: 110
Severity: Low
Contract: BaseRegistrarImplementation
Function name: [available(uint256), available(uint256)] (ambiguous)
PC address: 4722
Estimated Gas Usage: 3414 - 38591
A reachable exception has been detected.
It is possible to trigger an exception (opcode 0xfe). Exceptions can be caused by type errors, division by zero, out-of-bounds array access, or assert violations. Note that explicit `assert()` should only be used to check invariants. Use `require()` for regular input checking.
--------------------
In file: flat_BaseRegistrarImplementation.sol:1443

previousRegistrar.state(bytes32(id)) == Registrar.Mode.Open

--------------------

ETHRegistrarController

Mythril Classic results for ETHRegistrarController are as follows. flat_ETHRegistrarController.sol line numbers reflect on the output of truffle-flattener contracts/ETHRegistrarController.sol.

==== Multiple Calls in a Single Transaction ====
SWC ID: 113
Severity: Medium
Contract: ETHRegistrarController
Function name: rentPrice(string,uint256)
PC address: 996
Estimated Gas Usage: 5179 - 79151
Multiple sends are executed in one transaction.
Consecutive calls are executed at the following bytecode offsets:
Offset: 2947
Offset: 3202
Try to isolate each external call into its own transaction, as external calls can fail accidentally or deliberately.

--------------------
In file: flat_ETHRegistrarController.sol:1467

function rentPrice(string memory name, uint duration) view public returns(uint) {
        bytes32 hash = keccak256(bytes(name));
        return prices.price(name, base.nameExpires(uint256(hash)), duration);
    }

--------------------

==== Dependence on predictable environment variable ====
SWC ID: 116
Severity: Low
Contract: ETHRegistrarController
Function name: register(string,address,uint256,bytes32)
PC address: 3552
Estimated Gas Usage: 2056 - 6247
Sending of Ether depends on a predictable variable.
The contract sends Ether depending on the values of the following variables:
- block.timestamp
- block.timestamp
- block.timestamp
Note that the values of variables like coinbase, gaslimit, block number and timestamp are predictable and/or can be manipulated by a malicious miner. Don't use them for random number generation or to make critical decisions.
--------------------
In file: flat_ETHRegistrarController.sol:1498

msg.sender.transfer(msg.value)

--------------------

==== Integer Overflow ====
SWC ID: 101
Severity: High
Contract: ETHRegistrarController
Function name: register(string,address,uint256,bytes32)
PC address: 5332
Estimated Gas Usage: 2333 - 9254
The binary addition can overflow.
The operands of the addition operation are not sufficiently constrained. The addition could therefore result in an integer overflow. Prevent the overflow by checking inputs or ensure sure that the overflow is caught by an assertion.
--------------------
In file: flat_ETHRegistrarController.sol:1411

add(mload(s), ptr)

--------------------

5.2 Ethlint

Ethlint is an open source project for linting Solidity code. Only security-related issues were reviewed by the audit team.

Below is the raw output of the Ethlint vulnerability scan:

ethregistrar

contracts/BaseRegistrarImplementation.sol
  36:36     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  60:42     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  65:15     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  73:16     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  73:48     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  75:23     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  83:39     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  85:15     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  89:47     warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  114:37    warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  118:35    warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members

contracts/ETHRegistrarController.sol
  53:63    warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  54:34    warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  61:64    warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members
  64:58    warning    Avoid using 'now' (alias to 'block.timestamp').    security/no-block-members

contracts/StringUtils.sol
  15:8     error    Avoid using Inline Assembly.    security/no-inline-assembly
  22:12    error    Avoid using Inline Assembly.    security/no-inline-assembly

✖ 2 errors, 15 warnings found.

root

No issues found.

5.3 Surya

Surya is an utility tool for smart contract systems. It provides a number of visual outputs and information about structure of smart contracts. It also supports querying the function call graph in multiple ways to aid in the manual inspection and control flow analysis of contracts.

Below is a complete list of functions with their visibility and modifiers:

Files Description Table

Contracts Description Table

Legend

Root Control Flow

6 Test Coverage Measurement

Testing is implemented using Truffle. 12 tests are included for the Root contract, and they all pass. 30 tests are included for the .eth permanent registrar, and they all pass.

We were unable to obtain code coverage numbers for the tests, but the audit team’s overall impression is that testing covers a high percentage of code branches. That said, the testing is weak, in particular regarding negative test cases and edge cases. As a specific example, changing the following in ETHRegistrarController.renew causes no test failures, which shows a serious lack of coverage:

// OLD: require(msg.value >= cost);
// NEW:
require(msg.value > 0);

Appendix 1 - File Hashes

The SHA1 hashes of the source code files in scope of the audit are listed in the table below.

Appendix 2 - Disclosure

ConsenSys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via ConsenSys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any Third-Party in any respect, including regarding the bugfree nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any Third-Party by virtue of publishing these Reports.

PURPOSE OF REPORTS The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of Solidity code and only the Solidity code we note as being within the scope of our review within this report. The Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond Solidity that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) – on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

LINKS TO OTHER WEB SITES FROM THIS WEB SITE You may, through hypertext or other computer links, gain access to web sites operated by persons other than ConsenSys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that ConsenSys and CD are not responsible for the content or operation of such Web sites, and that ConsenSys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that ConsenSys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. ConsenSys and CD assumes no responsibility for the use of third party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

TIMELINESS OF CONTENT The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice. Unless indicated otherwise, by ConsenSys and CD.