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

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

That is not a good comparison in my opinion. Those third-party plugins for
WordPress (or Drupal or any other CMS) typically have a vendor page,
versions, changelogs, repos, etc. It is extremely rare there isn't
provenance on who wrote that code, or where it is/was maintained. These
contracts are a very different thing.

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

As an example, here are two contracts with the same name, associated with
two different tokens. Can you see a way to determine if they are the
'same' contract, in the sense of the author? Or is this a likely case of
copy/paste? I think this would also make MERGE decisions problematic.

7/3/2018        AssetToken      vl coin (vlcn) 
https://etherscan.io/address/0x0bdbc0748ba09fbe9e9ed5938532e41446c2f033

7/3/2018        AssetToken      BitRS (BitRS)   
https://etherscan.io/address/0x6248211b830ce0191c7643b19f5ddb059e018672

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

"Is it trackable in a meaningful / helpful way" should be a requirement.
That is my argument here.

: > 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?

I'm asking where the value is. If the CVE description can't give someone
actionable information, and they haven't been (largley due to not
including the address of the contract), what value does it bring? As a

consumer of CVE, it would require a lot of digging to ultimately hit the
same point I did on a lot of these; a given blob of code, that may or may
not be copied, with no known author or other provenance, that likely can't
be assigned meaningful CPE (i.e. would be missing at least one component
of the string, the vendor), and may or may not have a 'solution' in the
form of deprecation and/or relcation. Basically, how does someone use the
current CVE entries for these to determine if it impacts them?

Brian