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

[Kurt Seifried <kurt@seifried.org>]

On Mon, Jul 9, 2018 at 4:45 PM, jericho <jericho@attrition.org> 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.

It is a block of code so I believe it should be covered (I would also say that services should be covered, and there is movement on that afoot). 

 

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

Has that been a requirement for CVE ever? There is a lot of OpenSource code that has questionable or unknown origins, and in some cases we do label things as being part of an ecosystem (e.g. "WordPress Plugin", most wordpress plugins have NOTHING at all to do with WordPress the company...). 

 

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).

So we maybe look at CVE MERGE, but XML hashdos had similar issues, people cutting and pasting.recycling stuff that was fundementally broken. 

 

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.

"Is it fixable" is not a requirement for a CVE. As for tracking most of the contracts can be tracked down. 

 

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.

I'm not sure what you're saying here, you're saying unless software/service has a good web page talking about it, we can't cover it? 

 

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.

I would strongly disagree here. 

 

Thank you,

Brian

--

Kurt Seifried
kurt@seifried.org