EVRF – Ethereum Vulnerability Reporting Framework

Any amount of security research, auditing, formal verification or bug bounty programs will never get around the fact that humans make mistakes. Security is not only defined by the software we write, equally important is how we react to vulnerabilities when they are found. In this post, I propose a decentralized autonomous organization called Ethereum Security Consortium (ESC) along with the Ethereum Vulnerabilities Reporting Framework (EVRF) that both exist to standardize disclosure, identification, naming and communication of security vulnerabilities related to Ethereum — our new decentralized web.

Consider this blog post an early draft for what will soon turn into an Ethereum Improvement Proposal (EIP).

Update: Thank you everyone for the positive feedback on this proposal. I have included various amendments and made the language a bit more consistent. This is still a work-in-progress.

Disclosure: This proposal is inspired by work done in PHP Standards Recommendation 9 and 10.

Preamble

EIP: (to be assigned) Title: Ethereum Vulnerability Reporting Framework Author: D. Olsson dick.olsson@senzilla.com Type: Meta Status: Draft Created: 2017-07-21

Abstract

The decentralized autonomous organization called Ethereum Security Consortium (ESC) is the maintainer of the Ethereum Vulnerabilities Reporting Framework (EVRF), which defines standard procedures around reporting, identification and disclosure of security vulnerabilities for projects in the Ethereum ecosystem.

The goal of this framework, and the reason for standardization, is to offer users a consistent and reliable disclosure process that will improve responsiveness, information accuracy and ultimately security of the ecosystem as a whole.

The processes described in this framework are derived from projects such as Debian and Drupal that have strong organization around security in their own ecosystems. This framework, however, has been adapted to the unique challenges of the decentralized web.

Motivation

On Ethereum, anyone is able to publish decentralized applications and smart contracts that store or handle lots of monetary value and other very important data. Secure best practices when writing software is of high importance. But even more important is a reliable protocol for reporting and disclosing security vulnerabilities when they are found. Because they will continue to be found as long as humans write software.

There are two aspects when dealing with security vulnerability disclosures: (1) how they are reported (2) how they are published to the general public. Today, there’s a lack of standardization in this area and users are given little guidance. Users are having to rely on blogs, Twitter accounts, Slack channels etc. This leads to inaccurate communication, confusion and opportunities for exploitation.

In a decentralized ecosystem largely built on-top of fat protocols, consensus algorithms and contract standards, there is also lots of opportunity to standardize on common procedure protocols. This framework was created for projects in the Ethereum ecosystem to standardize around security vulnerability reporting and responsible disclosure.

The framework has been organized in such a way that there is no central organization to receive, judge or prioritize vulnerability reports. Although convenient and often efficient, such an organization could become a bottleneck and might not align with the interests of a decentralized ecosystem. This is why projects are responsible for organizing their own disclosure process according to this framework. A decentralized organization does exists, however, but merely to distribute said disclosures to the wider security community and to interact, on the behalf of the Ethereum community, with traditional central entities such as MITRE’s CVE database.

Framework

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Ethereum Security Consortium

The Ethereum Security Consortium (ESC) is a decentralized autonomous organization of volunteers that maintain this Ethereum Vulnerability Reporting Framework (EVRF) document, which defined standards processes around disclosure, identification and communication of security vulnerabilities for software projects in the Ethereum universe.

A unique identifier SHALL be assigned by the ESC for each security vulnerability published by projects according to the section Disclosure Process for Projects. A CVE identifier MAY also be requested by the ESC for identified vulnerabilities.

An XML repository, as defined by the OVAL Language schema, SHALL be provided by the ESC to allow for automated communication of vulnerabilities across tools and services of the wider security community.

An email address SHALL be provided by the ESC so that anyone MAY responsibly disclose security vulnerabilities in projects that do not follow Disclosure Process for Projects or do not provide other means for responsible disclosure. In this case advice SHALL be provided by the ESC for what the best course of action is.

A public OpenPGP key (as defined by RFC 44880) SHALL be provided by the ESC and any email communication from this email address SHALL be signed. Communication MAY be encrypted if the original sender also provides a public key.

Disclosure Process for Projects

The following sections describe the process by which any Ethereum projects are RECOMMENDED to (1) handle their security reporting process, and (2) how and in what format to publish security vulnerabilities.

1.a. Reporting Process Discovery

Every project MUST provide a link to its security reporting process in an obvious place. This SHOULD be on the root page the main domain of the given project. This MAY be a sub-domain in case it is a sub-project of a larger initiative. The link MAY use the custom link relation vuln-reporting, for example <link rel="vuln-reporting" href="http://example.org/security" />.

Projects SHOULD make the location prominent by either creating a dedicated sub-domain like http://security.example.org or by making it a top level directory like http://example.org/security. Projects MAY choose to list any part of the procedures that is not a MUST, which they choose to omit.

Note that projects MAY not have a dedicated domain. For example a project hosted on Github, Bitbucket or other service SHOULD ensure that the process is referenced on the landing page. For example, http://github.com/example/somedapp should have a README file on the default branch which references the procedures used so that it is automatically displayed.

If necessary projects MAY have different reporting process for different major version number. In this case one URL MUST be provided for each major version. In the case a major version is no longer receiving security fixes, instead of a URL, a project MAY opt to instead simply note that the version is no longer receiving security fixes.

1.b. Reporting Process

Every project MUST publish an email address on the page where it is describing its Reporting Process. Projects SHALL NOT use contact forms for this purpose.

At the same location as the email address, projects SHOULD publish a public OpenPGP key by which all communication will be signed. Communication MAY be encrypted, if the original sender also provides an OpenPGP public key.

2.a. Publishing Process Discovery

Every project MUST provide a link to its vulnerability information database in an obvious place. This SHOULD be on the root page of the main domain of the given project. This MAY be a sub-domain in case it is a sub-project of a larger initiative. If the project has a dedicated page for its Reporting Process Discovery, then this is also considered a good place for this link. The link MAY use the custom link relation vuln-publishing, for example <link rel="vuln-publishing" href="http://example.org/disclosures" />.

Note that projects MAY choose to host their disclosure files on a domain other than their main project page. It is not RECOMMENDED to store the disclosures in a VCS, as this can lead to confusion about which branch is the relevant branch. If a VCS is used, then additional steps SHOULD be taken to clearly document to users which branch contains all vulnerabilities for all versions. Projects with multiple major versions MAY split disclosure files by major version number, which SHOULD be clearly documented.

2.b. Publishing Process

Disclosures SHOULD first be published in the disclosure file (as described by the Publishing Format) before any other communication is published, for example, on social media.

For vulnerabilities that knowingly have not yet been exploited, it is RECOMMENDED to publish disclosures on Tuesdays around 17:00 UTC. This recommendation exists to maximize the potential availability of organizations and individuals to react to disclosures.

2.c. Publishing Format

Every project MUST provide its disclosure file formatted as JSON (as defined by RFC 7159).

2.c.1. Root object

The disclosure file MUST be a JSON document and MUST contain the following top-level keys with corresponding values:

name

MUST contain the name of the project.

description

MUST contain a short description of the project.

homepage

MUST contain a URL to the project homepage.

vulnerabilities

MUST be an array of zero or more JSON objects.

2.c.2. Vulnerability objects

Keys and corresponding values for each object in the top-level vulnerabilities key:

id

MUST be a per-project unique vulnerability ID integer.

title

MUST contain short description of the vulnerability and affected versions.

description

MUST contain description of the vulnerability.

affected

MUST be an array of affected version(s) expressed as [npm’s semver ranges][npm].

severity

MUST be expressed as a CVSS 3.0 vector string. It’s RECOMMENDED to use the CVSS 3.0 calculator for this purpose.

remediationType

MUST be either “workaround”, “mitigation”, “vendor fix”, “none available” or “will not fix” as defined by the CVRF v1.1 remediation types.

remediation

MAY contain a textual description for how to fix an affected system.

published

MUST be date and time of initial publication, formatted according to RFC 3339.

updated

MAY be date and time when the publication was updated, formatted according to RFC 3339.

authors

MAY contain an array of contact information about the authors of the remediation.

reporters

MAY contain an array of contact information about the reporters of the vulnerability.

links

MAY contain an array of URLs referencing more information. It is RECOMMENDED to include a link to the VCS reference of the remediation.

Appendix A: Sample publishing format

Below is an example implementation of the disclosure file format:

{ “name”: “somedapp”, “description”: “Some decentralized application doing something very useful.”, “homepage”: “http://somedapp.org”, “vulnerabilities”: [ { “id”: 2, “title”: “Re-entry vector in FooBar contract”, “description”: “Re-entry attack vector in the FooBar constructor that’ll lock out contributions to the contract.”, “affected”: “>=0.2.0”, “severity”: “CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H”, “remediationType”: “workaround”, “remediation”: “You must move funds in FooBar to another contract.”, “published”: “2017-07-20T18:00:00Z”, “updated”: “2017-07-20T20:00:00Z”, “authors”: [“maintainerX”], “reporters”: [“researcherY”, “researcherZ”], “links”: [“http://somedapp.org/security/vuln-2"\] }, { “id”: 1, “title”: “Information enumeration in FooBar contract”, “description”: “Enumeration of property ABC is possible due to improper hashing.”, “affected”: “>=0.1.0”, “severity”: “CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N”, “remediationType”: “workaround”, “remediation”: “You must move funds in FooBar to another contract.”, “published”: “2017-07-15T18:00:00Z”, “authors”: [“maintainerX”], “reporters”: [“researcherY”], “links”: [“http://somedapp.org/security/vuln-1"\] } ] }