Developer Resources
Block ExplorerGitHubRun a NodeMigration GuideETN Testnet Faucet
  • Overview
  • Foundational topics
    • Intro to the Electroneum Smart Chain
    • Intro to ETN
    • Intro to dapps
    • Web2 vs Web3
    • Accounts
    • Transactions
    • Blocks
    • Electroneum Virtual Machine (EVM)
      • Opcodes
    • Gas and Fees
    • Nodes and clients
    • Networks
    • Consensus mechanisms
      • IBFT
  • Electroneum Stack
    • Intro to the stack
    • Smart contracts
    • Development networks
    • Development frameworks
    • Electroneum client APIs
      • JavaScript APIs
      • JSON-RPC
    • Storage
    • Integrated Development Environments (IDEs)
    • Metamask
  • Advanced
    • Bridges
    • Standards
      • Token standards
        • ERC-20 Fungible Tokens
        • ERC-721 NFTs
    • Oracles
    • Networking layer
      • Network addresses
    • Data structures and encoding
      • Patricia Merkle Trie
      • Recursive-length prefix (RLP)
      • Web3 secret storage definition
  • Design fundamentals
    • Intro to design and UX
  • ETN-SC Client
    • Getting started
      • Introduction
      • Hardware requirements
      • Instaling ETN-SC
    • Fundamentals
      • Command-line options
      • Security
      • Sync-modes
      • Account management
      • Databases
      • Backup & restore
      • Logs
      • Connecting to peers
      • Pruning
      • Private networks
      • Config files
      • Light client
    • Interacting with ETN-SC
      • JSON-RPC Server
        • Batch requests
        • Real-time events
      • JSON-RPC Namespaces
        • admin
        • clique
        • debug
        • eth
        • istanbul
        • les
        • miner
        • net
        • personal
        • txpool
      • JS Console
      • JS Console 2: Contracts
      • GraphQL Server
    • Developers
      • Introduction
      • Dapp developers
        • Dev mode
        • Go API
        • Go Account Management
        • Go Contract Bindings
      • EVM tracing
        • Introduction
        • Basic traces
        • Built-in tracers
        • Custom EVM tracer
        • Tutorial for JavaScript tracing
      • ETN-SC developer
        • Developer guide
        • Disclosures
        • DNS discovery setup guide
        • Code review guidelines
      • Contributing
    • Monitoring
      • Creating Dashboards
      • Understanding Dashboards
      • Ethstats
      • Metrics
    • Tools
      • Clef
        • Introduction
        • APIs
        • Rules
        • Setup
        • Datatypes
        • Tutorial
        • Clique-signing
      • abigen
      • devp2p
    • FAQs
  • Migration to Smart Chain
    • Overview
    • How to Migrate
      • ETN Online Wallets
      • Paper Wallets
      • CLI Wallet Users
      • Exchange Holders
      • Exchanges
    • Bridge Smart Contract
  • Misc. Guides
    • Set up Ledger + Metamask
  • MY.ELECTRONEUM.COM
    • Vendor API
Powered by GitBook
On this page
  • Why silent patches
  • Public transparency
  • Disclosed vulnerabilities
  • What about GitHub security advisories
  • Bug Bounties

Was this helpful?

  1. ETN-SC Client
  2. Developers
  3. ETN-SC developer

Disclosures

PreviousDeveloper guideNextDNS discovery setup guide

Last updated 1 year ago

Was this helpful?

In the software world, it is expected for security vulnerabilities to be immediately announced, thus giving operators an opportunity to take protective measure against attackers.

Vulnerabilities typically take two forms:

  1. Vulnerabilities that, if exploited, would harm the software operator. In the case of Etn-sc, examples would be:

    • A bug that would allow remote reading or writing of OS files, or

    • Remote command execution, or

    • Bugs that would leak cryptographic keys

  2. Vulnerabilities that, if exploited, would harm the Electroneum Smart Chain mainnet. In the case of Etn-sc, examples would be:

    • Consensus vulnerabilities, which would cause a chain split,

    • Denial-of-service during block processing, whereby a malicious transaction could cause the network to crash.

    • Denial-of-service via p2p networking, whereby portions of the network could be made inaccessible due to crashes or resource consumption.

In most cases so far, vulnerabilities in Etn-sc have been of the second type, where the health of the network is a concern, rather than individual node operators. For such issues, Etn-sc reserves the right to silently patch and ship fixes in new releases.

Why silent patches

In the case of Electroneum, it takes a lot of time (weeks, months) to get node operators to update even to a scheduled hard fork. If we were to highlight that a release contains important consensus or DoS fixes, there is always a risk of someone trying to beat node operators to the punch, and exploit the vulnerability. Delaying a potential attack sufficiently to make the majority of node operators immune may be worth the temporary loss of transparency.

The primary goal for the Electroneum team is the health of the Electroneum Smart Chain network as a whole, and the decision whether or not to publish details about a serious vulnerability boils down to minimising the risk and/or impact of discovery and exploitation.

At certain times, it's better to remain silent. This practice is also followed by other projects such as .

Public transparency

Our policy on public transparency is:

  • If we silently fix a vulnerability and include the fix in release X, then,

  • After 4-8 weeks, we will disclose that X contained a security-fix.

  • After an additional 4-8 weeks, we will publish the details about the vulnerability.

We hope that this provides sufficient balance between transparency versus the need for secrecy, and aids node operators and downstream projects in keeping up to date with what versions to run on their infrastructure.

Disclosed vulnerabilities

The JSON file of known vulnerabilities below is a list of objects, one for each vulnerability, with the following keys:

  • name

    • Unique name given to the vulnerability.

  • uid

    • Unique identifier of the vulnerability. Format ETN-SC-<year>-<sequential id>

  • summary

    • Short description of the vulnerability.

  • description

    • Detailed description of the vulnerability.

  • links

    • List of relevant URLs with more detailed information (optional).

  • introduced

    • The first published Etn-sc version that contained the vulnerability (optional).

  • fixed

    • The first published Etn-sc version that did not contain the vulnerability anymore.

  • published

    • The date at which the vulnerability became known publicly (optional).

  • severity

    • Severity of the vulnerability: low, medium, high, critical.

    • Takes into account the severity of impact and likelihood of exploitation.

  • check

    • This field contains a regular expression, which can be used against the reported web3_clientVersion of a node. If the check matches, the node is with a high likelihood affected by the vulnerability.

  • CVE

    • The assigned CVE identifier, if available (optional)

What about GitHub security advisories

We prefer to not rely on GitHub as the only/primary publishing protocol for security advisories, but we plan to use the GitHub-advisory process as a second channel for disseminating vulnerability-information.

Bug Bounties

In keeping with this policy, we have taken inspiration from - see below.

There is a JSON-formatted list () of some of the known security-relevant vulnerabilities concerning Etn-sc.

Etn-sc has a built-in command to check whether it is affected by any publically disclosed vulnerability, using the command etn-sc version-check. This command will fetch the latest json file (and the accompanying , and cross-check the data against its own version number.

Advisories published via GitHub can be accessed .

The ETN-Network runs a bug bounty program to reward responsible disclosures of bugs in client software and specs. The details are provided on our page.

Bitcoin
Solidity bug disclosure
vulnerabilities.json
signature-file
here
bugcrowd