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

[jericho <jericho@attrition.org>]

Apologies, one more thing came to mind:

6. It can be argued that many of these Smart Contract issues are not 
vulnerabilities at all. For example, an integer overflow in the 
mintToken() or mint() function, which can only be called by the 
contract 
creator, allows them to mint arbitrary tokens. This does not appear to 
cross privilege boundaries either. If that function could be called by 
anyone on the chain or interacting with the contract, that would of 
course 
cross privilege boundaries. That said, a majority of these require the 
owner of the contract to call the vulnerable function.

Brian

On Mon, 9 Jul 2018, 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
: 
: