Bitcoin core security is the main issue

Bitcoin Core is the foundation of a network that secures over 2 trillion dollars worth of value. There are high stakes, and many parts of the code base can have serious bugs. Security vulnerabilities exist in areas such as the peer-to-peer message processing (p2p), cryptographic libraries and the consensus engine. These can lead to thefts, halting the network or destroying trust. Bitcoin is not like traditional financial software that has insurance or legal recourses. Its security depends entirely on its code quality and processes to maintain it.

Bitcoin Core’s approach to security isn’t formally defined. Instead, it has evolved over time. The review processes are more detailed, the testing infrastructure is more extensive, and as a project, we have been more cautious and deliberate in our software changes. Slower pace reduces the chance of new bugs being introduced by hasty changes.

The article examines the security of Bitcoin Core from several angles: 

• The disclosure policy is the procedure for dealing with vulnerabilities discovered 
• The extensive fuzzing network that hunts bugs
• A broader set of testing tools that detects issues and fixes them before they are in production 

They are not a single strategy but rather complementary defenses that were developed over time as the project evolved.

Vulnerability Information Disclosure Process

Bitcoin Core is a project that does not provide automatic updates for software. This protects its users from its developers. All released binaries are compared to the source code published by reproducible builds. The Node Runners are in charge of determining which software version to use and when to update. This poses a problem in the context of security flaws. It is important to have the fixes available as open-source for the review and release process, while also delaying full disclosure to allow time for users to update.

In the past, the public disclosure by project of critical security vulnerabilities was inadequate, regardless of whether they were reported from outside or found by users. Many users believed that Bitcoin Core had no bugs. This was a very dangerous and incorrect perception. Motivated by these problems, about a year ago and a half, the project revised, formalized, and improved its handling of security concerns. disclosure policy The advisory process. It was a goal to increase transparency, to set expectations clearly for security researchers, to better inform them of the dangers of outdated software, to communicate more effectively the risk of using it, and to make the security bug available after its disclosure so that others can learn and avoid future vulnerabilities.

Policy

All vulnerabilities should be reported to security@bitcoincore.org (see SECURITY.md for details). Each vulnerability that is reported will receive a severity rating. There are four different types of vulnerability:

CriticalBugs which threaten fundamental integrity and security in the Bitcoin network. This is a bug that allows coin thefts at the protocol-level, creation of coins beyond the schedule specified, or permanent network-wide chains splits.

High QualityBugs which have an impact of a large scale on nodes and the network. The bugs can be exploited remotely and cause widespread damage.

MediumBugs with a noticeable impact on the performance or functionality of a node or network, yet limited in scope. Some of these bugs require specific conditions in order to be triggered, for example, non-default setting, or they may result in a service degradation, rather than complete node failure.

Low-costBugs which are difficult to exploit, or that have only a small impact on the operation of a node. These bugs may only trigger under certain non-default settings or via the local network and they do not present an immediate threat.

Low-cost Two weeks will pass after a fix has been released in a major release. Medium You can also find out more about the following: High Quality The severity of the vulnerability will be revealed 2 weeks after End of Life for the latest affected version (roughly one year after a first major release containing the patch was released).

The details on a security vulnerability will not be released until two weeks after the pre-announcement. Pre-announcements will be made two weeks prior to the actual release. They contain details of all the vulnerabilities that have been fixed and the severity of each one.

Critical As they are likely to require an ad hoc procedure, bugs do not fall under the policy. Bugs may also not be a security vulnerability. A reported problem may be deemed serious but not warrant an embargo.

Bitcoin Core’s team verifies any reported vulnerability before it can be used. “Security Team”The project categorizes vulnerabilities into four severity levels: Critical (threats to network integrity like coin theft or inflation), High (significant impact, remotely exploitable), Medium(performance degradation or limited scope) and Low(difficult to exploit with minor impact). The project divides vulnerability severity into four categories: critical (threats against network integrity such as coin theft and inflation), high (significant impact remotely exploitable), medium (performance degradation, limited scope) and low (a difficult to exploit bug with a minor impact). A fix will be developed, and tested thoroughly in secret, once the vulnerability is confirmed to be serious. This fix will be submitted in a PR just like every other code change. But the PR discussion and description blur the truth about the nature of this fix. This fix might be described as a “refactoring”, “performance improvement” or “hardening against possible issues”. The fix can then be submitted to normal code reviews while the details of the vulnerability remain private.

The approach is not without its challenges. Maintaining the balance can be a real challenge. Some critics might say that this approach is paternalistic, or concentrates power too heavily in the hands a small group of developers. They know vulnerabilities well before anyone else. Although these concerns should be taken seriously, the consequences of a public announcement could prove disastrous. Publication of vulnerability details prior to the update by most users gives attackers both the target (unupdated devices) and weapon (exploit codes).

Fuzzing Infrastructure

Fuzzing, also known as randomization, is a technique for finding bugs in software by feeding it randomized inputs. Fuzzers use evolutionary algorithms that learn what inputs cause interesting code paths and then change those inputs in order to probe deeper into the software. This is a great way to detect edge cases that are difficult to uncover through code reviews or manual testing.

As the fuzzer will be providing inputs, developers cannot state directly what they expect (e.g. that input A should yield output B). Instead, they assert general characteristics the software must maintain. It is a very valuable tool, because it helps us build confidence that the software will behave as expected by checking properties like preventing the network from crashing and ensuring coin supply does not exceed what we expect.

Bitcoin Core has a high level of fuzzing due to the need for security and robustness. Fuzz testing has been increasing in Bitcoin Core over the years. Early mentions of primitive fuzzing date back as far as 2012 The integration of the simple framework for fuzzing occurred in 2016The framework has evolved to include over 200 fuzz tests that cover critical components and functions in the codebase.

Fuzz tests are not defined by a standard unit test. “pass” point, i.e. If you run them only once, they will not work. “passed” The following are some examples of how to use “failed” The status of the return. As fuzzing involves a random process that is ongoing, statements made about results (when there are no bugs found) will only be probabilistic. Fuzz tests can run continuously for up to 5000 hours before a flaw is discovered. To be truly effective, the fuzz test must run constantly. Bitcoin Core relies on Google’s oss-fuzz It also invests heavily in its own infrastructure, and several contributors are constantly fuzzing their own setups. For example: BrinkBitcoin Core is fuzzed by a single’s Infrastructure, which provides over 1 million CPU-hours per year.

The Bitcoin Core repository includes numerous fuzz tests on the component/function levels, but several other projects use different fuzzing techniques. Now retired Cryptofuzz was a project that focused on differentially fuzzing libsecp256k1 code and other cryptographic components. The project also included non-cryptographic codes, like serialization primitives and consensus logic. bitcoinfuzz Uses a Bitcoin-specific differential fuzzling approach. With the help of fuzzing, a full-system approach is being created to discover bugs at system level. FuzzamotoThis is used to find bugs that are caused by complex interactions of different code bases working as one system. 

There are hundreds, if no thousands, of insects that have been discovered. found by fuzzing In released Bitcoin Core version or pull requests over the years, (obviously some of which are not security-relevant), highlight the importance and effectiveness of fuzzing. This is a high-severity example that was recently published. CVE-2024-35202The discovery involved refactoring the compact block relay logic, extracting it into its own isolated and testable module and writing a fuzz test for it. It was discovered by extracting and testing the logic of compact block relays and refactoring them into their own module.

Quality Assurance

Although fuzzing was highlighted in the previous section, the project also employs other methods of testing on a regular basis. This helps to reduce the chances that issues will reach production code.

Bitcoin Core contains hundreds of unit test. The tests verify small pieces of code such as functions and classes. As an example, unit testing is used to check the behavior of a function for proof-of-work. In these tests, edge-case inputs are provided to the function in order to test whether the outputs met expectations.

Functional tests, on the other, test a single Bitcoin Core instance or multiple instances in their entirety, verifying the behavior of the system at a high level by using external interfaces (e.g. To simulate real-world scenarios, RPCs and p2p messaging can be used. A test of this type could, for instance, create a network of small nodes and submit a payment to each of them. The wallet RPCs are used to verify that the entire network of nodes has observed the transaction and approved it. Bitcoin Core was historically lacking in code modularity. This characteristic is still present today. A functional test approach has been adopted by the project, rather than a traditional unit-testing one. This is because the code must be refactored in order to isolate it for independent testing.

Each test methodology has both strengths and weakness. The unit test is a fast way to find bugs, and it is also a good method of locating them. By definition, unit tests will not detect any bugs that are only caused by the interactions of several units. Functional tests are the best because they test the entire system, but at the expense of speed. They have to create and remove node instances for each test. These tests also do a much poorer job of indicating where the bug is. In the previous example, the failure of the propagation test (i.e. It is difficult to determine which parts of the system have a bug. This could be due to a problem with the logic of mempool accept, or the code for networking, RPCs that were used to create the transactions, or other components. The best method to use is a combination of methods.

Every PR is run through the CI, as well as every push of the master branch. The unit, fuzz and functional tests are all run on a variety of host OSs, CPU architectures, and bug detection tools, including the Address, Thread, Undefined and Memory sanitizers, and valgrind, to detect common C++ bugs relating to undefined behavior and memory safety.

Bitcoin Core evolved incrementally from the client Satoshi originally released. Contributors came and went over time, so there is a large amount of legacy code. It has and continues to be a major part of work in the Bitcoin Core project, refactoring the existing code. This is done to make it simpler and easier for the user. All of these things require refactoring, regardless if it’s for the Kernel. There are differing opinions on how and when to refactor, since it is a two-edged sword. Refactoring can be scary, as it may introduce new bugs, but also refresh the context of those who are involved. Functional tests, and testing at the system-level (such as Fuzzamoto in the section on fuzzing) can be used to reduce the risk of refactoring. This is because these tests require very little refactoring.

The project, as part of its testing strategy prior to major releases and as a way to encourage users to check out new and established features, produces a guide to help them test it manually. As a general call to action to ensure that the normal workflow of each user is maintained, testing software using typical use is encouraged.

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

The latest issue of the magazine features a Letter to the Editor. Print This is the core issue of Bitcoin Magazine. This is a preview of the entire issue.