recent wave of Smart Contract vulns - out of scope?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

recent wave of Smart Contract vulns - out of scope?

jericho

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


Reply | Threaded
Open this post in threaded view
|

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

Kurt Seifried-2


On Mon, Jul 9, 2018 at 4:45 PM, jericho <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

jericho

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

Reply | Threaded
Open this post in threaded view
|

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

jericho
In reply to this post by jericho

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
:
:
Reply | Threaded
Open this post in threaded view
|

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

Kurt Seifried-2
In reply to this post by jericho


On Mon, Jul 9, 2018 at 5:20 PM, jericho <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

jericho

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

Meaning you know the SSH client exists for iOS, but couldn't find the
app/vendor on the store? If so, that would be similar to Dormann's Tapioca
project, some 23k+ vulnerable apps. Even a week after the disclosure, many
of the apps had been removed from the store. We were able to dig up the
app/vendor using third-party sites that mirror the Android store to pull
information missing in the original disclosure. So in those cases, we have
the software's provenance. If there is an app that completely vanished,
and no indication it ever existed via Google searches, that is tricky. How
do we even know it was a legit app in the first place, and not malware
being distributed on a third-party store?

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

Except, we don't. MITRE/CVE/Researchers have not been including the
contract address in the CVE IDs. That is obviously fixable, and should be
mandatory for any smart contract disclosure, regardless of the outcome of
this thread.

Also, a contract can interact with SoarCoin but have nothing to do with
the coin otherwise. People using SoarCoin aren't impacted unless they
interact with the vulnerable contract. So the presence of a dozen
contracts on Ethereum that are vuln, has no bearing on the security of
Ethereum itself. We've seen that with 'game' contracts earlier this year,
where the vulnerability allowed for badthing that could result in loss of
funds, but only for those playing the game via the contract. Unrelated to
CVE's trackign of these, I wouldn't say it is fair to ding SoarCoin or
Ethereum for a vulnerability in a third-party contract, just as we don't
with WP or Drupal plugins and their main software.

Brian

Reply | Threaded
Open this post in threaded view
|

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

Pascal Meunier
In reply to this post by jericho
Contracts are a different form of open source code than what we're used to, but should
be covered by the CVE, changing our methods and criteria if need be.  The goal is to
have a CVE to identify the issue when discussing it.  I believe it is sufficient that
the code be identifiable, even if it is anonymous and may slightly vary from instance
to instance.  However, the level of abstraction of assigning one CVE for each is sub-
optimal, because they are individual instances of the same.

I don't see the absence of attribution, provenance, or person to pin it on, as a
reason to not cover these when that information is not available in practice.  The
difficulty may be defining the group that would be covered by a CVE.  It seems similar
to the problem of recognizing cheating in programming assignments, but from a
different perspective.  The difference between that and a CWE would be that the CVE is
specific to closely related code instances, and code excerpts should be recognizable
as cut-and-paste.

Even if existing instances are not patchable or upgreadable, people can take note of
the CVE and attempt to fix the problem when creating more instances;  there will be a
beneficial effect.

Pascal

On Mon, 2018-07-09 at 17:45 -0500, 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
>
>