CVE's for "smart" contracts, legal execution engines
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.
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]
Re: CVE's for "smart" contracts, legal execution engines
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
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.