Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to carry out the CVE-2010-5141 loophole of arbitrary Bitcoin theft. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Bitcoin vulnerability CVE-2010-5141 this vulnerability can cause attackers to steal anyone's Bitcoin, which is very harmful. Fortunately, the vulnerability has not been exploited, and the repair speed is extremely fast. The vulnerability is related to Bitcoin's script engine and is of reference significance for public chain developers. Judging from the current public chain in the market, most of them have built-in virtual machines or script engines to create DApp ecology, and it is also one of the major trends of blockchain.

What is the UTXO model in Bitcoin?

Tips: some UTXO-related knowledge and concepts will be involved in the vulnerability code snippet, so you need to know these knowledge points before theoretical analysis of the vulnerability, and those you already know can be skipped directly.

Ⅰ, account Model and UTXO Model

Let's talk about the common account model before we look at the UTXO model. What is the account model? The simple data structure of the account model can be understood as "account = > balance", and each account corresponds to a balance. For example, if account A transfers 200 to account B, it only takes Amure 200 and then Bany200 to complete the transfer in the account model; at present, most software uses the account model, such as banking system, Etay Square and so on.

On the other hand, Bitcoin uses the self-developed UTXO model, and there is no data structure such as "account = > balance" in UTXO, so how to transfer money?

How to operate money transfer with Ⅱ and Bitcoin

Taking the transfer from A to B as an example, the following actions are required to complete the transfer in UTXO:

1. Find the source of more than 200 under An account, which means to find the transaction x in which A receives 200.

two。 Taking the transaction x as the input and the transaction y transferring 200 to B as the output, x corresponds to y and the amount of transfer between x and y must be equal

3. X transactions are marked as spent and y transactions are marked as unspent

And the transfer amount of the two transactions must be equal, the simple explanation is that you can only transfer as much as you receive, which is indeed the case.

But what happens when you have to transfer only part of it to someone else? The answer is to transfer only part of it to others, and then transfer the rest to another account.

Ⅲ, quote two pictures and texts from the network:

Account model

UTXO model

In this article, why Bitcoin uses the UTXO model is not the point, we can understand the principle of UTXO.

Second, the script engine of bitcoin

Bitcoin scripts are not Turing complete. Bitcoin uses a self-defined script for transactions and other operations, providing Bitcoin with limited flexibility. Implement simple functions such as multi-signature and freezing funds, but more are not.

The reason Bitcoin does this is to sacrifice a certain amount of completeness to ensure security. The principle of a Bitcoin script is that a bunch of opcodes are defined, and then the script engine executes each opcode one by one based on the stack.

The stack is easy to understand, while the queue is first-in-first-out, while the stack is just the opposite, first-in, first-out, where an element is pop after it is pushed into the stack (push).

Sending a standard transfer (pay-to-pubkey) transaction in earlier versions of Bitcoin requires a script signature (scriptSig) and a public key verification script (scriptPubKey), as follows:

First fill in the script to be executed (Script), then the signature (sig) and public key (pubKey) are pushed into the stack, and then the opcode OP_CHECKSIG will verify the signature, etc., if the verification is passed, the true will be pushed into the stack, otherwise the false will be pushed into the stack.

III. Vulnerability Analysis of CVE-2010-5141

With the above knowledge, you can begin to analyze the CVE-2010-5141 vulnerability. The author downloaded the vulnerable version 0.3.3, and the download address looked for release in github's bitcoin repository.

Script.cpp code snippet VerifySignature function:

Each transaction executes a call to the VerifySignature function, which executes the script and verifies the signature, and then marks whether the transaction is spent.

First of all, the txFrom parameter is the previous transaction, and txTo is the transaction being processed, which is not difficult to understand if you understand the UTXO model explained in the above chapter. Focusing on 1125 lines of code, the EvalScript function is called. The first parameter is txin.scriptSig (including signature information) + delimited opcode OP_CODESEPARATOR+ txout.scriptPunKey (including public key information, OP_CHECKSIG instruction). These are the scripts to be executed by the EvalScript function. The following parameters can be ignored for the time being, as long as the EvalScript function returns true, then the verification signature is passed. How can the EvalScript function return true?

First, the stack cannot be empty, and then the top of the stack must be true after the bool is forcibly turned. The author simply interprets that there must be a top of the stack and the value cannot be 0.

Then look at the key OP_CHECKSIG opcodes.

(note: because there are too many opcodes, this article aims at OP_CHECKSIG opcodes.)

According to the normal logic of OP_CHECKSIG, if the signature verification is not successful, a vchFalse will be left at the top of the stack. Although the stack is not empty, the value at the top of the stack is 0, and false will be returned.

Going back to the previous code, the script executed by the EvalScript function consists mainly of the following variables:

1. Txin.scriptSig

2. OP_CODESEPARATOR

3. Txout.scriptPubKey

The first signature information is controllable, the second is just a separator and will be deleted, and the third is uncontrollable because it comes from the previous transaction.

The first variable is controllable and executed as a script, so this variable can be not only signature information, but also opcode, which is easy to do. We need to quote a magic opcode OP_PUSHDATA4. Let's see how Bitcoin 0.3.3 handles this opcode:

First get the opcode. If the value of the opcode is less than or equal to the value of OP_PUSHDATA4, press vchPushValue into the stack, and then follow up the GetOp function

After reading the source code, it is found that the OP_PUSHDATA4 instruction is defined as 78, so when the function encounters OP_PUSHDATA4, the pointer will move another 78 bits, in which 78 bits of data will be pushed into the stack, so as long as an OP_PUSHDATA4 opcode is injected into the txin.scriptSig, the subsequent public key information and OP_CHECKSIG instructions will be "eaten" and put into the stack as parameters. When the pointer comes to the end, make the final judgment:

1. Is the stack empty? No

two。 Is the top element of the stack 0? No

So the conditional EvalScript function returns true, and then the VerifySignature function also returns true, and now that signature verification is bypassed, other people's bitcoins can be spent at will.

IV. CVE-2010-5141 vulnerability repair scheme

The author downloaded Bitcoin version 0.3.8 and looked directly at the key parts of the code.

The fix is also clear: separate the scriptSig from the scriptPubkey, no matter what is in your scriptSig will not affect the later scriptPubkey execution.

Write at the end

Because the Bitcoin loophole comes from 2010, the material can be said to be quite old. At present, there are mainly the following difficulties in vulnerability analysis:

1. There is very little information related to vulnerabilities, and most vulnerabilities have only a CVE number and profile, so there is no way to start without consulting a large number of data.

two。 It is difficult to build an environment, such as compiling and building private chains (there was no concept of private chains in the early days of bitcoin). Many of the dependencies needed for the early compilation of bitcoin source code are now unmaintained and offline.

This is the end of the analysis on how to carry out the arbitrary Bitcoin theft loophole CVE-2010-5141. I hope the above content can be of some help to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.