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

道歉,忽然想起一件事:6。可以说,这些聪明的合同问题是没有漏洞。例如,整数溢出的mintToken()或薄荷()函数,它只能被称为合同的创造者,允许他们任意牌薄荷。这一切似乎并未跨越特权的界限。如果这个函数可以调用链或交互与合同上的任何人,当然跨特权边界。说,大部分的这些要求合同的所有者调用脆弱的函数。布莱恩在星期一,2018年7月9日,耶利哥写道:::CVE委员会::在过去的几周,已经有一系列的披露:智能合同中的漏洞。这些基本上是blob的代码:生活在一个网站,管理一个给定的合同相关区块链/令牌。:近500的这些披露最近,大多数CVE作业,我相信这些范围。进一步,他们是有问题的跟踪:其他的原因。 Please consider: : : 1. :https://etherscan.io/address/0xb57aff26bbb822c06e81f194ec5ca29319d6d7b4代码::这是一个脆弱的合同,和他们住在网站:如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 : :