Topic: [SECURITY] DoS Vulnerability (Read 2702 times)

Good to see that this has been tested before, and doesn't seem to pose any significant risk.

There was some talk about this in another thread as well:
https://bitcointalksearch.org/topic/bitcoin-virus-559365

This method really depends quite a bit on how each AV scans files.

Still going on today with Windows 7 running MS Securities Essentials.

1. MS SE flagged the problem
2. When I allowed it to proceed, bitcoin core 0.9.0 aborted
3. I updated MS SE to exclude the chainstate directory
4. I restarted bitcoin core.

Problem solved. Definitely a (minor) annoyance.

They can very precisely detect from which location the detection comes from and adjust their software with the next updates, so no need to "whitelist" a known virus signature (which is the whole issue with false positives). Also, most AV definitions don't run by string-based definitions alone anymore since a long time (except for very old, simple malware) or very cheap AV programs.
It's the combination of factors that gets a file blocked.

Most data-processing software suffers from generating look-alikes to known definition due to the sheer randomness of the data streams they produce (i.e. DC programs running under BOINC processing and generating very large data volumes), so the issue is pretty old.

It'll likely take the AV guys a few weeks but it will get sorted out.
Anyway, it's a non-issue in the long run the way I see it. Actively contacting them about a false positive (or the whole issue) will also help speed up the process.

https://www.virustotal.com/de/file/46e101bfc027339afc82825472e7e9bb36d8a5fbaa9dd6fbc45b5dd7ffd67fe9/analysis/1396646034/
freshly triggered by Avira Free AV

My tought was more that the AV companies cannot do anything to the problem, since deleting the false positive also means they need to delete a signature for a real virus, so it would be a moment 22, either they need to delete the recongnizition for both a harmless file and a dangerous file, OR they need to keep both.

About the viruses: Most viruses have a very strict definition in the AV database (sometimes a md5 hash requiring a strict bit-to-bit match), causing the AV program from not detecting. In gmaxwell's example.
But the guy did do a "signatures.bin" containing all these adresses but in binary format, and here is the result:
https://www.virustotal.com/en/file/ad3579ca4dbcec8e255c3137d3be6655b953f0ce366c96682f9bc34982b7719e/analysis/1396453693/

The "viruses" used needs to be carefully selected so these are homomorphic (eg Changes its payload each time) so only a small subset of the virus can be detected reliable, and then this small subset is used in a BTC transaction.

There are two easy solutions to this non-issue :

AV companies will very quickly recognize the findings in the Blockchain as false positives and react appropriately (they're legally bound to act this way).
Therefor, this will never spread to other AV companies other than false positives, which they will take care of within days.

Having a "malfunctioning" AV program only requires the blockchain file to be excluded from being scanned - problem solved.

False positives have been out there for a long time and it's a rare occasion if one causes a malfunction or even data loss. When that happened in the past, the AV guys quickly got into hot water and fixed it ASAP.
Plus, most AV programs don't simply destroy their next best find (especially not when based on heuristics), the User will at best get a notification window for a temporary blocked application with request for the desired action by the user.

When it comes to base security that could actually challenge bitcoin's survival :
I'd rather shit my pants from the prospect of a network-based zero-day exploit one day. Now that would be really bad news.

This is hyperbole, pure and simple.

I just updated ClamAV and ran it against the testnet to see if it catches any of gmaxwell's "viruses":

I stuffed some AV definitions into the testnet chain years ago and _no one_ has ever reported an AV hit on it. Obviously we can obscure the blockchain from things like that, but so far there appears to be no reason to do so.

Do you actually have evidence of some AV software noticing signatures inside the blockchain files?

AFAICT you don't. Even if it were to occur only a fraction of bitcoin nodes run on windows/mac systems with that kind of nutty AV software, so we could simply deploy an update which obfuscated the block files if it ever were an issue. You should take more care with your claims of doom, chicken little.

Found this DoS Vulnerability. Since its already in the wild on a Swedish forum, here comes:

https://www.flashback.org/t2349003
(Thread in Swedish).

But here comes explaination:

What the OP in the Flashback thread says, its a DoS vulnerability in that Bitcoin allows you to create arbitary transactions containing arbitary data. So what he does, was to search Anti-virus definitions after sequences that is common in BTC network (0x76 0xA9 0x14) - OP_DUP OP_HASH160 length=20bytes.
When he finds this, he then takes the next 20 bytes of that antivirus definition, and convert this to a valid Bitcoin Adress.

He then sends some coins to this adress.

The result: The blockchain will contain occurences of 23 bytes that will match a Anti-Virus definition.
If the def matches a small virus and also the antivirus uses heuristics, then the antivirus will react violently on the blockchain.

He have already done a list of 442 adresses that each is a found entry in a antivirus def database for a specific AV vendor.
He says that if he does a list of all these adresses for all vendors and then make sure each adress get some payment, then EVERY AV vendor will react on the blockchain, which will cause shutdown and erasure of the whole blockchain (because every node's antivirus will erase the BTC chain) and the Death of bitcoin is immient.



Solution:
Force client to encode the transaction in some unpredictable way that the client cannot Control over, or have the miner to "blind" the transaction with a blinding factor, that then requires a node to cooperate with a miner to successfully execute a attack.
Also the enconding/blinding can also be based on previous block and/or nonce to further make the attack even more difficult.
The encoding factor/blinding factor is of course embedded in the transaction so anyone on the network can "unfold" the transaction and read it in cleartext.

But this also requires that transaction handling does not store raw transaction data in RAM, instead this must be stored in some obfuscated way too. (and of course the obfuscation itself must not trigger AVs)

This prevents the client from making transactions that intentionally will trigger other node's antivirus solutions.