智能合同vulns - Re:最近一波的范围?

合同是另一种形式的比我们用来开源代码,但应该覆盖的CVE,如果需要改变我们的方法和标准。我们的目标是有一个CVE来识别问题在讨论它。我认为它是足够的代码是可识别的,即使它是匿名的,可能稍微不同实例的实例。然而,抽象级别分配的CVE为每个子任务最优,因为他们都是相同的单个实例。我看不出没有归属的情况下,出处,或人销,理由不介绍这些当信息在实践中是不可用的。困难可能定义组将由反暴力极端主义。看起来类似于认识到作弊的编程作业的问题,但是从不同的视角。之间的区别,和CWE CVE是特定于密切相关的代码实例,和代码摘录应该识别剪切和粘贴。即使不是patchable或upgreadable现有的实例,人们可以注意的CVE并尝试解决这个问题在创建多个实例;将会有一个有益的效果。 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代码> >这是一个脆弱的合同,和他们住在web etherscan.io等> >网站。因此,的范围作为一个“服务”> >漏洞尚未覆盖的CVE风格。> > 2。该合同是一个随机的代码块>不能>归因于供应商。尽管合同名称可能AIChain和>与AIChain的令牌,这并不意味着有一个>作者令牌的创造者和合同之间的关系。>合同创造者只被称为链上的一个地址,例如>https://etherscan.io/address/0x8a8690d3ffaeeb700fe8be7a86b145b64922ec15> > 3。这些合同都是互相复制/粘贴,这是> >为什么我们看到很多这样的披露。有几个>人/组>做大部分的信息披露,并简单地扫描链上的所有合同> >(如ethereum)寻找blob的脆弱的代码。我们> >不知道一个人写了原始的脆弱的代码,复制> > 500次(可能),或者如果数百写同样脆弱代码> blob >(不太可能)。> > 4。用户不能安装一个补丁或升级来解决这样一个脆弱的合同> >。这个代码不是区块链本身的一部分,还是>钱包/客户最终用户安装。在大多数情况下,>脆弱的合同将被弃用,一个新副本将旋转> >新地址我相信。如果代码是固定的合同>创造者>在同一地址,会有任何迹象显示,我是固定> >。所以我们甚至不一定会得到一个“2018-07-09”之前>风格>符号,更不用说一个版本或者其他方式来跟踪合同。 > > 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 > >