NEO DoS Vulnerability Patched

The NEO Foundation recently issued a statement about a Denial of Service (DoS) vulnerability on the NEO platform that has been discovered and patched. The vulnerability was pointed out in a blog post by Zhiniang Peng from Qihoo 360 Core Security. The security team compiled a detailed report after identifying and testing the vulnerability, which was submitted to NEO as a bug report on August 15th. Following the fix, the team was awarded 1,000 NEO for the discovery and disclosure of the vulnerability.

The vulnerability was found within the Smart Contract platform, specifically the System.Runtime.Serialize system call, which did not take into consideration nested arrays. A bug in how nested arrays are de-serialized could cause an infinite loop until the stack-space was exhausted.

At this point, a StackOverflowException would be triggered. The NeoVM is built to handle exceptions, but with this StackOverflowException, the entire process terminates which prevents the handling code from executing. This in turn would crash NEO’s nodes that were attempting to parse the malicious contract, preventing the network from functioning. A full explanation of the issue can be found in the original post from Qihoo 360 Core Security.

Zhiniang Peng commented: “It is worth mentioning that within 7 minutes after we emailed the NEO official to notify this vulnerability, Erik Zhang, one of the founders of NEO, replied directly to confirm the existence of the vulnerability and submitted the bug fix within an hour. Their efficiency is quite amazing.”

NEO Accidental Fork

In addition to the vulnerability patch, NEO also recently experienced an accidental blockchain fork. A blockchain fork occurs when two blocks are propagated to the network, each with the same block height and pointing to the same previous block, but with different block hashes. As this appears as one chain splitting into two independent chains with a shared history, it is known as a fork.

In a blockchain network that uses Proof-of-Work or Proof-of-Stake consensus, each side of the fork can continue to have blocks added to it by the miners or validators on the network. Whichever side of the chain is longest is usually deemed to be the truthful chain, resulting in any transactions inside blocks on the forgotten half of the fork being reversed. These blockchains use confirmations to calculate the risk of a transaction being lost in this way.

In NEO’s case, consensus is achieved using a 66% quorum of consensus nodes, rather than individual competing validators or miners proposing their own blocks. This ordinarily prevents more than one block being validated at a time, which prevents forks from occurring. It also grants NEO same-block finality, as confirmations are no longer required to trust a transaction’s permanence.

Instead of a fork as they are conventionally understood in the blockchain community, NEO’s fork was instead caused by a rare issue in consensus where two valid blocks were proposed. If both blocks receive enough signatures from consensus nodes, this causes a single block fork. Although this did not actually stall consensus, it did create confusion amongst nodes as they became stuck on the conflicting block.

This caused some intermediate nodes, such as those used by light wallet clients like Neon, from being able to remain synchronized with the network. As a result, light wallets and exchanges experienced outages despite NEO’s consensus continuing as normal. These outages continued until the nodes became re-synchronized.

The solution to this issue is to add a third stage to NEO’s consensus mechanism, which is a solution that has been in development by CoZ member Shargon since July 16th. NEO’s dBFT originally used a 2-phase protocol with ‘pre-prepare’ and ‘prepare’ phases to allow consensus to occur more quickly. With Shargon’s third ‘commit’ phase added to the protocol, consensus becomes more secure due to what is essentially a double-check of the block hash before it is propagated.

The changes will add a slight delay to consensus in return for full fork prevention, but these delays are expected to be invalidated by upcoming optimizations to the dBFT protocol in the near future. Amongst other optimizations, one proposed solution by developer Toghrul Maharramov would theoretically combine the ‘pre-prepare’ and ‘commit’ phases into a single phase to increase the efficiency of consensus.

Tags: