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

[jericho <jericho@attrition.org>]

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