CVE's for "smart" contracts, legal execution engines

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

CVE's for "smart" contracts, legal execution engines

Kurt Seifried
So you may or may not heard of an incident with respect to the Ethereum currency/blockchain and a smart contract that was executed resulting in approximately $50 million in funds being transferred to an individual.

https://news.ycombinator.com/item?id=11928092
https://news.ycombinator.com/item?id=11925904

The media is generally using terms like "attack" and "hack", so let's assume for a moment this is an attack (and not a legal but crafty method to obey the letter of the law as it were, but bypass the spirit) and that Ethereum/smart contracts are classed as a software rather then a service (again, I can see arguments going both ways). My thought is much like a protocol vulnerability (e.g. CVE-2009-3555) we need to think about and be ready to assign CVE's for these types of issues, at a minimum I think we can all agree that a smart contract execution engine that has some "Classic" type of flaw like a buffer overflow would deserve a CVE, but within the context of a legal contract execution engine I would think that it can be argued the execution of the legal argument is similar to code in that you can have language that exploits certain weaknesses or ill defined cases resulting in behavior that is obviously unwanted and not what the creators of the system had in mind when they created it (like some random person taking $50 million in funds). 

So the main issues that need to be dealt with:

1) Where do we draw the line on software/service for blockchain technologies? 
2) Where do we draw the line for legal/contract execution security vulnerabilities? Can it to be in something that "ships" like a standard legal contract for rental of a property for example?
3) Where do we draw the line on "letter of the law" vs. "spirit of the law", e.g. in computers memory corruption/manipulation violates what the code creator probably wanted, but was allowed by the code. I would like to avoid the need for court cases to decide these issues before a CVE can be assigned =). 

Do we have any lawyers familiar with legal contract execution engines? I suspect there aren't many of those.

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CVE's for "smart" contracts, legal execution engines

jericho
On Mon, 20 Jun 2016, Kurt Seifried wrote:

: So the main issues that need to be dealt with:
:
: 1) Where do we draw the line on software/service for blockchain
: technologies?

Historically, the line has been drawn around the end-user software. So a
vulnerability in the actual downloaded client qualifies for inclusion. A
vulnerability in the 'math' behind the implementation is typically seen as
a hybrid issue, or considered more a service offering. Issues in the
algorithm or implementation that can be abused via the client software
would fall under consumer software I believe, and warrant inclusion.