Go through all BTC CVE

[bokobza]

This task can be divided into 2 parts:

1. Create a list of known bitcoin vulnerabilities
2. check whether the source code has protection mechanism against each and every one of those vulnerabilities

Also, for each vulnerability, add comments supporting your findings.

[Aprogiena]

[bokobza]

CVE-2012-4684 We don't have alerts anymore so that's easy ✔️

[DanGould]

@Aprogiena Where is that list coming from? bitcoin.it wiki's list seems comprehensive

[Aprogiena]

https://youtu.be/Cpid31c6HZc?t=2h52m33s

[DanGould]

Progress thus far noted: Should be through most of the bitcoin list by the weekend. Still must check in on the Etherium CVEs. I will update this comment with the status of the CVEs

CVE	Affects	Flaw	Comments
Pre-BIP protocol changes	all clients	various softforks & hardforks	We validate the Protocol?
CVE 2010 5137	wxBitcoin & bitcoind	OP_LSHIFT crash	Disabled in ScriptEvaluationContext.cs:696
CVE-2010-5141	wxBitcoin & bitcoind	OP_RETURN can steal funds	We independently EvalScript scriptSig using shared stack so SBFN is good
CVE-2010-5138		unlimited SigOp Dos	Check SigOpsRuleTest.cs
CVE-2010-5139		Combined output overflow	Check for negative or overflow output values in Transaction.cs
CVE-2010-5140	wxBitcoin & bitcoind	never confirming txs	No micropayment fee TransactionBuilderContext.MinConfirmations defaults to 1
CVE-2011-4447	wxBitcoin & bitcoind	Wallet non-encryption	We use actually use json formatted wallet .dat. This doesn't run into the non-ACID problems of BerkelyDB does it?
CVE-2012-1909	Bitcoin protocol and all clients	Transaction overwriting	DeploymentFlags.EnforceBip30 Checks block height & hash for 2 bitcoin blockchain exceptions
CVE-2012-1910	bitcoinqt & bitcoind for windows	Fail to use MinGW multithread safe exception handling	SBFN doesn't use MinGW
BIP-0016	All bitcoin clients	Mandatory P2SH	Thanks NBitcoin and a mature existing blockchain
CVE-2012-2459	bitcoind & bitcoin-Qt	block hash collisions via merkle root	BlockMerkleRootRule.cs
CVE-2012-3789	bitcoind & bitcoin-Qt	Lack of orphan Txn resource limits	❗ 1: LimitOrphanTxSize (possible vuln) size of an individual OrphanTx / pool of Orphans is unlimited even though // DoS prevention: do not allow mapOrphanTransactions to grow unbounded in MempoolOrphans.cs V2: OrphanTxs stored in dictionary and searched by hash so this should be good (no worry of O(n) step search)
CVE-2012-4682	bitcoind & bitcoin-Qt	DoS	❔ Little detail on actual vulnerability revealed
CVE-2012-4683	bitcoind & bitcoin-Qt	targeted dos by CPU exhaustion using alerts	SBFN does not use alerts
CVE-2012-4684	bitcoind & bitcoin-QT	Network wide DOS using malleable sigs in alerts	SBFN does not use alerts
CVE-2013-2272	bitcoind & bitcoin-Qt	remote discovery of a node's wallet addresses	❗ Our Mempool doesn't give penny-flood rate limit exception to one's node's addresses so we should be good with this CVE but may be vulnerable to a penny-flood (low fee spam)
CVE-2013-2273	bitcoind & bitcoin-Qt	predictable change outputs	TransactionBuilder.cs:106 should add correct randomness (no off by 1)
CVE-2013-2292	bitcoind & bitcoin-Qt	transaction takes 3 minutes for client to verify	❗ Optimized in Core by Core pull#7907
CVE-2013-2293	bitcoind & bitcoin-Qt	Continuous disk seek/read	❗ do we implement checks on whether spent prevouts are checked It looks like we don't when reading disk in DbreezeCoinView.cs
CVE-2013-3219	bitcoind & bitcoin-Qt 8.0	Unenforced block protocol rule	We don't use BDB and so lack an implicit lock limit rule--explained in BIP-50
CVE-2013-3220	bitcoind & bitcoin-Qt	inconsistent BDB lock limit interactions	BIP50 supported
BIP-0034	all bitcoin clients	Sofftfork: height in coinbase	covered
BIP-0050	all bitcoin clients	Hard fork to remove txid limit protocol	covered
CVE-2013-4627	bitcoind & bitcoin-Qt	Memory Exhaustion with excess Tx message data	Txs Serialized properly in AddOrphanTx via nMaxOrphanTx
CVE-2013-4165	bitcoind & bitcoin-Qt	timing leak in rpc authentication	❗ str.Equals (RPCAuthorization.cs:36) vulnerable to timing attack. This appears to secure the vuln
CVE-2013-5700	bitcoind & bitcoin-Qt 0.8.0	remote p2p crash via bloom filters	❗ NBitcoin.BloomFilter doesn't have a div by 0 test
2014	bitcoin	unhandled point at infinity pubkey recovery
CVE-2014-0160	Anything using OpenSSL for TLS	HeartBleed - Remote memory leak via payment protocol	This issue is resolved in OpenSSL after 2014
CVE-2015-3641	bitcoind & bitcoin-Qt before 0.10.2	Yet unspecified DOS	❔ Unspecified
BIP-0066	All bitcoin clients	Softfork: Strict DER Signatures	Enforced in DeploymentFlags.cs
BIP-0065	All bitcoin clients	Softfork: OP_CHECKTIMELOCKVERIFY	Enforced in DeploymentFlags.cs
BIPs 68, 112 & 113	All bitcoin clients	Softforks: Rel locktime, CSV & MTP Locktime	Enforced in DeploymentFlags.cs
BIPs 141, 143 & 147	All bitcoin clients	Softfork: Segwit	Implemented in NBitcoin etc.
CVE-2017-9230	Bitcoin	ASIC Boost	❗ 0% Coverage among modern clients (still no solution) - not relevant to PoS
BIP 148	All bitcoin clients	Softfork: Segwit UASF	Wedunnit
CVE-2017-12842(June 9 2018)	?	Spoof transactions to spv nodes (Does this affect our lite node?)	We don't support an SPV wallet :)
CVE-2016-10724	bitcoind & bitcoin-Qt prior to 0.13.0	Alert memory exhaustion	SBFN does not use alerts
CVE-2016-10725	bitcoind & bitcoin-Qt prior to 0.13.0	Final Alert cancelation	SBFN does not use alerts
2016	Etherium	Uncle mining, an etherium consensus protocol flaw	Our "uncles" (orphans) don't secure the protocol
2016	bitcoin	A bitcoin transaction that takes 5 hours to verify	❗ Optimized in Core by pull#7907
2014	BitcoinJ	BouncyCastle ECDSA BJB-22 vulnerability (unhandled point at infinity recovery)	❔ This was patched in BC. a BigInteger BouncyCastle vuln was also patched in NBitcoin by BU researchers this summer :) we should still check it because our BouncyCastle is manually ported from Java rather than relying on a lib

[bokobza]

The wallet encrypts the private key of the HD wallet using Key.GetEncryptedBitcoinSecret(password, network) in NBitcoin who in turn uses SCrypt.BitcoinComputeDerivedKey which is an implementation of BIP38.

[dangershony]

Great work @DanGould we will verify all the findings when the node is stable.

[DanGould]

After speaking with Ethan, I found out that the Core devs' policy is now to not disclose CVEs because they don't want to be responsible for alts' follies. Notice reporting drops significantly after 2015.

He mentioned their new practice to find some small bug which, when fixed, patches a vulnerability without ever disclosing that vulnerability. He mentioned a few in particular with no documentation and that core devs involved with MIT DCI speak openly about this practice as evidence. This practice is reflected in the little information on many bugs provided on the bitcoin.it wiki

tldr;

The most historically vulnerable attack surfaces are the Mempool and Transaction verification. I advise we compare present /bitcoin/bitcoin's implementations of these functions with SBFN's and closely match their logic to avoid exposure.

[Fishbiscuit]

May I ask if there is a list of Bitcoin versions that resolve these CVEs?

[DanGould]

May I ask if there is a list of Bitcoin versions that resolve these CVEs?

https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures Click the "net" link on the right side of the row corresponding to the CVE. Shows the list of versions vulnerable at the bottom. Generally, if you search the CVE on GitHub you find the issue which addressed the vulnerability

[EthanHeilman]

Disclaimer: I in no way speak for the core devs

I just want to poke my head in to say that I am not aware of any official policy of the core devs to not disclose vulnerabilities. However there was a period in which a number of vulnerabilities were patched but not disclosed. This was likely because of a concern of them being exploited against unpatched nodes in the wild. This has not been the case for a while and last few vulnerabilities have been disclosed and assigned CVE numbers for instance CVE-2018-17144.

The closest thing to a policy is the Security_md in the bitcoin git repo and it does not take any stance on disclosure.