recent wave of Smart Contract vulns - out of scope?

[jericho <jericho@attrition.org>]

CVE Board,

In the last couple of weeks, there have been a string of disclosures 
around vulnerabilities in Smart Contracts. These are basically blobs of 
code that live on a web site that manage a given contract related to a 
blockchain/token. With almost 500 of these disclosed recently, most with 
CVE assignments, I believe these to be out of scope. Further, they are 
problematic to track for other reasons. Please consider:

1. 
https://etherscan.io/address/0xb57aff26bbb822c06e81f194ec5ca29319d6d7b4#code

That is an example of a vulnerable contract, and they live on web sites 
such as etherscan.io. As such, that is out of scope as a 'service' style 
vulnerability not currently covered by CVE.

2. The contract is little more than a random block of code that cannot be 
attributed to a vendor. While the contract name may be 'AIChain' and 
associated with the 'AIChain' token, that does not mean there is a 
relationship between the token creator and the contract author. The 
contract creator is only known as an address on the chain, e.g. 
https://etherscan.io/address/0x8a8690d3ffaeeb700fe8be7a86b145b64922ec15

3. These contracts are copy/pasted from each other heavily, which is why 
we're seeing so many of these disclosures. There are a few people/groups 
doing a majority of the disclosures, and simply scanning all the contracts 
on a chain (e.g. ethereum) looking for the vulnerable code blobs. We don't 
know if one person wrote the original vulnerable code and it was copied 
500 times (likely), or if hundreds wrote similarly vulnerable code blobs 
(unlikely).

4. A user cannot install a patch or upgrade to fix a vulnerable contract 
like this. This code is not part of the blockchain itself, nor the 
wallet/client the end-user would have installed. In most cases, the 
vulnerable contract would be deprecated and a new copy would be spun up on 
a new address I believe. If the code was fixed by the contract creator at 
the same address, there would be no indication of when it was fixed that I 
can see. So we wouldn't necessarily even get a "before 2018-07-09" style 
notation, let alone a version or some other way to track the contract.

5. A majority of these tokens don't even have a vendor page or GitHub that 
I have been able to find. So even trying to track it by the token becomes 
problematic as we can't reference a vendor, software, or version number in 
a majority of cases. Compare this to the actual blockchains such as 
Bitcoin, Ethereum, Litecoin, etc, that have web pages, code repos, and 
software that is installed by the user, it further contrasts that the 
contracts are not the same as the blockchain themselves.

As such, I propose that the board discuss and MITRE consider if these are 
worth assigning CVEs to. If these are found to be out of scope, I 
recommend that future assignments scrutinize if the vulnerability is in a 
contract or an actual blockchain, as well as REJECTing the curent set of 
IDs covering smart contract vulns.

Thank you,

Brian