Dry goods | "false rights" attack on chain structured PoS systems (Part-1)

Editor's Note: This article is an article published by Decentralized Systems Lab to discuss the security of PoS systems using the longest chain of rules. According to a certain division method, the PoS system can be divided into chain-based and BFT-Style; the vulnerability described in the article is in the chain structure system, so it is related to Cosmos. The Byzantine fault-tolerant PoS consensus algorithm like Tendermint has nothing to do; Casper doesn't use the longest chain rule, but the Latest Message Driven Ghost, so it's not related to the vulnerability mentioned here.

This article was published by the Decentralized Systems Lab at the University of Illinois at Urbana-Champaign (@ UIUC). A student research team consisting of Sanket Kanjalkar (sanket1729, [email protected]), %20Yunqi), Yuqi Li, Yuguang Chen, and Joseph Kuo, under the leadership of Andrew Miller (socrates1024), discovered some vulnerabilities that caused resource exhaustion. This article is made for public disclosure.

These vulnerabilities have affected more than 26 types of PoS-type cryptocurrencies. Through these vulnerabilities, an attacker can destroy any network node running related software with a small amount of equity. Prior to this public disclosure, we began planning to notify the affected cryptocurrency development team in October 2018. Most teams (based on market capitalization) have deployed countermeasures.

Proof of Entity (PoS) cryptocurrency , especially those based on the PoSv3 (third version of Equity Proof) on the chain, which are similar to Bitcoin, using the untraded transaction output (UTXO) model and the longest chain consensus. rule. The main difference is that the former replaces the proof of work (PoW) with proof of ownership of the token. The potential benefits of PoS include the ability to reduce the impact on the environment and increase resistance to 51% of attacks. Many cryptocurrencies are actually a fork (at least a derivative) of the Bitcoin code base and incorporate the functionality of PoS. However, because they blindly copied some of Bitcoin's design concepts, leaving a security risk, there have been some new vulnerabilities that did not exist in the original code base.

• Blockchain in the brokerage industry "money way"
• The SEC issues regulatory guidelines: such digital currency is not a "securities"
• Thunder: The big step is to transform to the blockchain, but commercialization is still a problem.

We refer to these vulnerabilities as "false rights" attacks. In essence, the attack is effective because PoSv3's programs do not adequately validate network data before issuing precious resources (hard disks and memory). Therefore, an attacker can use a small amount of equity shares (and in some cases even zero shares) to fill a node's hard disk and memory with spurious data, causing it to crash. We believe that all equity proof models based on UTXO and the longest chain principle are susceptible to such “false equity” attacks. After investigation and research, we have discovered a number of cryptocurrencies with vulnerabilities and attached a list at the end of the article.

Next, we will explain these vulnerabilities and attack techniques in detail, because they will have some undetectable consequences. Although it seems that these vulnerabilities are simple in the future, it is still difficult to solve them once and for all, and existing solutions may lead to forks (explained later).

background

Before delving into the details of these vulnerabilities, we will briefly introduce some background on the principles of the PoS mechanism on the chain.

Proof of interest mining:

Similar to PoW mining, PoS mining also compares the hash of the block head to the difficulty target. The goal of PoS is to ensure that each individual's probability of dug out the next block is proportional to the amount of tokens they pledge. To achieve this goal, the hash of the chained structured PoS mechanism depends not only on the block header, but also on the number of tokens that the equity owner pledges through a particular “coinstake” exchange in the block. This article will cover some specific details about PoS mining. A more detailed explanation can be found in Earlz's blog. This article focuses on the PoS mechanism from both the 1) coinstake transaction and the 2) the UTXO spent on the coinstake exchange.

The workload demonstrates the role of saving block verification resources:

As we all know, PoW plays a vital role in the Bitcoin consensus mechanism, but it also has a less important role in controlling access to the node's limited resources, such as disk, bandwidth, memory, and CPU. In a license-free public network, one node cannot trust other peers. Therefore, in order to prevent resource exhaustion attacks, the Bitcoin node must first check the workload proof of the block, and then decide whether to spend more hard disk or memory resources to store this block. However, the facts show that checking the proof of interest is much more complicated than the proof of proof and more sensitive to the environment. Therefore, many chained structure PoS mechanisms are seriously under-invested in effective verification.

In order to understand the causes of resource exhaustion vulnerabilities, we must detail how the blocks are stored before being verified. A node not only keeps track of the longest chain at the current time, but also tracks an entire chain of branches (because any one of the forked chains is likely to be the longest chain, in which case the node needs to be "reorganized" to switch To the new longest chain). For example, improper upgrades, double-strike attacks (for example, ETCs that suffer from 51% attacks), or temporary network partitions can all trigger this situation.

It is very difficult to verify the blocks on these non-main chains. To fully validate a block, you need a collection of undoed tokens (UTXOs) in the previous block. Bitcoin holds the UTXO collection at the top of the longest chain, but does not save the state of the UTXO collection at the time of the previous block (although it is possible to form a fork on any of the previous blocks). There are two main ways to fully verify the blocks on the forked chain:

1. "rollback" the current view (UTXO collection) before the fork start point;
2. Stores the UTXO state of each block before it.

(Proofreading Note: (in the blockchain of the UTXO model) After processing all the transactions contained in all the blocks in a chain, a set of UTXOs is formed, which is the latest state of the chain. Therefore, even if On the same chain, the state of the #100 block (UTXO collection) is different from the state of the #101 block. The above means that although each block may form a fork, the bit The coin software does not save a copy of each block state, but only saves the latest UTXO collection; if the state of each block is saved, this will become a large storage overhead. .)

The Bitcoin code base does not support the second method, and even if it does, it adds extra storage costs (the performance of Bitcoin's nodes depends on drastically reducing unnecessary data). The Bitcoin code base is currently using the first method to handle reorganization. However, the cost of frequent rollbacks is also very expensive, so rollback and full verification do not occur when there is a fork, but wait until the workload on the forked chain proves to actually exceed the current main chain. Will only proceed. Therefore, when a peer node receives a block or block header on a non-longest chain for the first time, we will skip the full verification and save the block in the local storage area.

Before storing this block into disk, the Bitcoin code base performs some preliminary verification based on the PoW mechanism (although the transactions within the block are ignored). Preliminary verification is only for the previous block header and the current block header, so the node is very fast to verify. And this is a very effective defense, because generating an effective proof of work to pass this initial verification is costly. For example, although it is possible to trick a Bitcoin node to store an illegal block on a hard disk, it is a very uneconomical behavior to initiate a resource exhaustion attack in this manner.

A similar preliminary verification process exists in the PoS mechanism, which is to verify the coinstake transaction and hash it with the kernel value of the previous block to see if the resulting hash value exceeds the difficulty target. It's easy to calculate the hash of a coinstake transaction. It's difficult to verify that the UTXO entered in the coinstake transaction is legal and not spent ; but to check if a UTXO has not been spent, you need the previous block of the transaction. The UTXO collection state; as we said above, nodes are often not specifically stored in such a state. Because it is very difficult to fully validate cointake transactions, most of the chain PoS mechanisms provide an empirical or approximate verification method as an alternative. It turns out that these alternative verification methods are often inadequate and flawed.

Vulnerability 1: "I can't believe there are loopholes that non-rights holders can attack."

 

When we first studied this vulnerability, we found that the five cryptocurrencies of Qtum, Particl, Navcoin, HTMLcoin, and Emercoin had this vulnerability, that is, the cointake transaction could not be verified before the block was submitted to the memory or hard disk. . What these five cryptocurrencies have in common is that they all use Bitcoin's “block-first” rule, which divides the block into two separate types of information—blocks and blockheads—for propagation. The block body information is requested only when the node confirms that the block header of a block has passed the PoW verification and the block follows the longest chain (or longer chain). Since the coinstake transaction exists only in the block body rather than in the block header, the node cannot verify only the block header, so the block header is directly stored in the internal data structure (mapBlockIndex). Therefore, any cyber attacker can maliciously fill a node's memory even if it does not hold any rights.

There is another form of this type of attack that can be implemented for the same code base, but in a slightly different way, and the attack target is also shifted from the node's memory resources to the hard disk resources. It can be said that the attack on the node hard disk is more harmful: if the node crashes due to the memory being filled up, it can be recovered by simply restarting. However, if the hard drive is full, manual intervention is required to recover (for example, running an external script to clear outdated blocks on the hard drive).

If the block is not the block header but the block body, the initial verification will be different. Ideally, because the coinstake transaction is included in the block, the node software should verify it and submit the block to the hard disk. However, as mentioned above, if the block is on a forked chain, it will be much harder for the node to access the UTXO spent on the coinstake exchange. Perhaps for this reason, these codebases do not validate cointake transactions.

For cryptocurrencies with any of the above vulnerabilities, even those who do not hold any rights can attack them. Resource-depleted attacks against memory are trivial. From a technical point of view, we need a dike-based resource-depletion-type attack on hard disks (although both are attacks that do not require any rights). If you want to know more details, you can read a short paper published in the 2019 Financial Cryptography Conference.

(unfinished)

Author: Decentralized Systems Lab Translation & proofreading: TrumanW & Min Min

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!