Re: recent wave of Smart Contract vulns - out of scope?

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

Contracts are a different form of open source code than what we're used 
to, but should
be covered by the CVE, changing our methods and criteria if need be.  
The goal is to
have a CVE to identify the issue when discussing it.  I believe it is 
sufficient that
the code be identifiable, even if it is anonymous and may slightly vary 
from instance
to instance.  However, the level of abstraction of assigning one CVE 
for each is sub-
optimal, because they are individual instances of the same.

I don't see the absence of attribution, provenance, or person to pin it 
on, as a
reason to not cover these when that information is not available in 
practice.  The
difficulty may be defining the group that would be covered by a CVE.  
It seems similar
to the problem of recognizing cheating in programming assignments, but 
from a
different perspective.  The difference between that and a CWE would be 
that the CVE is
specific to closely related code instances, and code excerpts should be 
recognizable
as cut-and-paste.

Even if existing instances are not patchable or upgreadable, people can 
take note of
the CVE and attempt to fix the problem when creating more instances;  
there will be a
beneficial effect.

Pascal

On Mon, 2018-07-09 at 17:45 -0500, jericho wrote:
> 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
> 
>