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

[Kurt Seifried <kurt@seifried.org>]

On Mon, Jul 9, 2018 at 5:20 PM, jericho <jericho@attrition.org> wrote:

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

Ok another real world example: I tried to track down all the SSH clients on the Apple iOS store, I wasn't able to for several of them. Does that mean they don't get covered by CVE?

 

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

Seeing as how we aren't short of CVE #'s anymore I would just split and maybe add a note in each one referencing each other. 

 

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

But it is trackable, and it is helpful. We have the wallet ID's/examples, and in the case of say SoarCoin people know now that the provider (Soar Labs) was engaged in some, shall we say shenanigans that mean you may want to avoid that coin. That's pretty useful. 

 

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

See above but one simple aspect is now I know that I might want to avoid that particular coin, or ensure I don't enter into any of the really bad contracts/reuse them. 

 

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

--

Kurt Seifried
kurt@seifried.org