'CVE' stands for "Common Vulnerabilities and Exposures".
It is typically instantiated as a worldwide list of vulnerabilities / exploits that have been found in a given program / software's code or environment / code.
The purpose of the CVE directory is to put users of a given product / software on alert that such a vulnerability ability may mean by means.
You want to be able to wrap your head around what's going on whenever there's a really serious (seemingly 'scary') CVE that's been released.
CVE Directory Resource
One of the more common resources for information on newly released / published CVEs can be found here on the U.S. government's website (NIST): https://nvd.nist.gov/general
Specifically, it states:
"The NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security related software flaws, misconfigurations, product names, and impact metrics."
CVE Metrics / Legend
Generally, each CVE is usually given 'scores' based on a number of criteria. '
Over time, the criteria used to generate each score has changed - but overall it appears most are satisfied with the rating system (this is honestly an assumption ; there could be some nerds somewhere hopping mad about it - but I've never seen it).
Where to Find More Information About CVE Metrics
This website appears to be a great start: https://www.first.org/cvss/user-guide
It would probably be preferable for most users if they selected version 3.1 as their CVSS changes guide.
We won't waste too much time here going through all of that, but for all those that are interested (because you're a super diligent beaver that's still somehow managed to find themselves nestled in the blockchain space), then you should go ahead, check out everything in that thread and then write us later on it).
The NIST is also nice enough to provide their very own CVE calculator (the method of usage should become immediately apparent to you after viewing the page and skimming the instructions at the top): https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
Given the nature of CVEs and Bitcoin's relatively infrequent appearance on the list because...you never know.
How We Ended Up Looking at This Specific CVE
I hate anticipatory drumrolls. So, for reference, the CVE in question here is CVE-2020-14198.
Weird Attempts to Obfuscate / Not Mention the Vulnerability
The CVE listed above (among a plethora of CVEs) can be found at this link (Bitcoin Wiki) = https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
Notably, all of the CVEs on the list are hyperlinked except for the last one at the bottom of the list (CVE-2020-14198).
Many of the worst CVEs that one can imagine have been discovered this year and are wholly related to the Lightning Network (which should drill in just how much counterparty risk one is taking by using this flimsy, entirely unsafe network that folks such as Jack Dorsey insist on promoting).
Fortunately, not all hope is lost if we wish to find the official entry for the CVE in the national database (United States / NIST; CVE-2020-14198). If you're wondering how to find this for yourself personally, you just need to look up the actual CVE code on Google (verbatim; again, that's ** CVE-2020-14198**).
More Details on the Recent Bitcoin CVE
If you followed those instructions above re: Googling, then you should end up at the following link: https://nvd.nist.gov/vuln/detail/CVE-2020-14198
Below is a screenshot to provide a direct visual:
Notably, there is no concrete information on what's going on, on the page itself - so we're still in the dark about this major vulnerability that's received a 7.5 / 10 CVE rating (not good).
However, there are three references that visitors are given if they wish to follow up on the situation (appears that one would have to if they wanted to find out any meaningful information about what's going on here re: this serious vulnerability).
The links provided above (in order) are:
- https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2020-14198 [Wholly Unhelpful]
- https://github.com/bitcoin/bitcoin/commits/master [this does not take us to the specific commit that addresses this vulnerability in the protocol]
- https://security.gentoo.org/glsa/202009-18 [the only concrete source of information for us to learn what's going on here with this vulnerability with a 7.5 rating that seemingly has no information]
Reading Through the Gentoo Triage
For some odd reason, the Gentoo triage is our most reliable frame of reference if we wish to truly know exactly what this latest CVE is about.
Again, that link can be found here (#3 on the list above) = https://security.gentoo.org/glsa/202009-18
That should take users to a page that looks like the following:
From here, you're going to want to click on the 'Bugzilla entries' link, located on the right hand side of your page:
Which should bring users to the following link: https://bugs.gentoo.org/711198
Check out the comments on the triaged request here for Gentoo (a Linux OS distribution):
Notably, Luke Dash Jr., is on the scene attempting to wrap his around what's going on (he's a Bitcoin Core developer).
Strangely enough though, he is of the opinion that activity resulting in unexpected behavior (i.e., a core dump that allow an attacker to recreate one's wallet master private key - a devastating form of compromise).
It took over four months before the issue was actually fixed / code merged upstream to mitigate this attack (keep in mind that this bugzilla conversation is public); from there, it was another **two months that news of this release went unannounced to the general public (remember, this was not published by the NIST until September 2020 - requesting all clients to bump beyond 0.20, the most recent Bitcoin version at the the time).
(Below is a look at the relevant release notes from the Bitcoin Core 0.20 reference client release):
site = https://bitcoin.org/en/release/v0.20.0 [notably, there wasd nothing about the vulnerability in the release notes or anything else ; this was released in June (2020)]
Perhaps the most troubling part about all of this is that Luke Dash insisted that there be nothing done to 0.20.0 to "stabilize" the release because there would be a 'hot fix' released soon for Bitcoin via 0.20.1 (apparently there was an even worse vulnerability that he was simply sitting on in his backpocket that he refused to tell anyone)
Above, we can see Luke Dash Jr., making a concerted effort to suppress the efforts of other developers from Gentoo that would have been more than happy to assist in favor of a Bitcoin Core reference client implementation that was riddled with vulnerabilities (yet the 'Knots' client wasn't).
What is the Bitcoin Knots Client?
Apparently, this is a Bitcoin Core developed client that's...better than Bitcoin Core (seriously).
Rather than being saddled down with many of the less-than-optimal default settings accompanied with Bitcoin Core (in addition to remedying some of the existing 'bugs', per the Knots documentation [why would any # of bugs be ok for end users of any client?]), there are a number of supposed enhancements that users stand to gain significantly from with this protocol as well.
The official site for 'Bitcoin Knots' can be found here: https://bitcoinknots.org/
Feature List for Bitcoin Knots
Only some of the enhancements under the 'functional and policy enhancements' section will be listed (brace yourselves):
- Parse URIs and non-BTC amounts
- Accept non-standard Bitcoin Transactions
- Support for Tonal Bitcoin (more on this at a latter point in time)
- Restore Ability to Display Addresses in GUI
- Add mempool stats collector
- Add paramater to addmultisigaddress / createmultisig to sort public keys
- Drop IO priority to idle while reading blocks for getblock requests.
- Refactor mempool.dat to be extensible, and store missing info.
- Integration with ZMQ (message broker software ; you'll have to look into this one if you don't know anything about it yet)
- Require input amount to be provided for witness transactions (this is pretty critical as it would prevent individuals from screwing you up via RBFs with a full blown fucking nap cycle)
- BIP174 support (complete / full ; PBST)
- Optimizing the 'siphash' implementation (wondering what there is to be optimized here ; why wouldn't the function already be optimize in the merged upstream master?)
- "Updated consensus checkpoints"
[list for us ends here...plenty more on the page though]
There are plenty of other features that on the Bitcoin Knots client that are enigmatically not available for the normal reference implementation client (Bitcoin Core).
It is not entirely clear why some of the more useful features (security-wise) would be relegated to this client implementation exclusively (without there being an explicit logic given by either the developers or the Core team as a unit).
Concrete Information About Vulnerability - Deals With 'Wallet.Dat' Encryption Mechanism
For some reason, an unforced 'core dump' on the Bitcoin Client (ref. implementation), causes a memory leak that makes the 'wallet.dat' file easily constructable in full by an attacker.
Thus, the threshold for doing so (if you're an attacker), is more than likely just mounting a successful DoS attack on your target which, as we've seen several times in the past on the Bitcoin protocol is a trivial task if said attacker is employed with a moderate amount of tools.
Addressing Weaknesses in the Wallet.Dat Encryption
The design of the wallet.dat file is weak - top to bottom. This critique has been brought to the attention of the Core team by Librehash already, but they have refused to answer because it appears that pretending that problems don't exist are more effective than actually solving them for the Bitcoin Core team (seriously).
Here is a write-up that we published not too long ago detailing the inefficiencies and points of weakness for wallet.dat