通过以太坊漏洞赏金计划，我们收到了关于新的实验性ABI编码器(名为ABIEncoderV2)中的一个缺陷报告。经研究，我们发现该组件存在一些相同类型的不同变化。本公告的第一部分详细解释了这个错误。新的ABI编码器仍然标记为实验性的，但我们认为这值得强调，因为它已经在主网上使用。
此外，优化器中的两个低影响bug在过去两周内已经被确定，其中一个bug已经在Solidityv0.5.6修复。两者都是在0.5.5版本中引入的。详情请参阅本公告的第二部分。
在0.5.7版本中，本文中提到的所有bug与漏洞都已经被修复。
这里提到的所有bug都应该在涉及相关代码路径的测试中很容易看到，至少在使用0和非0值的所有组合运行时是这样。
感谢Melonport团队(TravisJacobs和JennaZenk)和MelonCouncil(NickMunoz-McDonald,MartinLundfall,MattdiFerrante和AdamKolar)，他们通过以太坊漏洞赏金计划报告了这些!
谁应该关注
如果您已经部署了使用实验性ABIencoderV2的合约，那么这些合约可能会受到影响。换言之，只有在源代码中使用以下指令的合约才会受到影响:
pragmaexperimentalABIEncoderV2;
此外，还有许多需要触发的bug。有关更多信息，请参阅下面的技术详细信息。
据我们所知，主网上有大约2500个合同使用实验ABIEncoderV2。尚不清楚其中有多少存在该bug。
如何检查合约是否受影响
只有当满足以下所有条件时，该bug才会出现:
涉及到数组或结构的存储数据直接发送到外部函数调用，发送到abi.encode或发送到eventdata，而无需事先分配给本地变量AND
数组包含大小小于32字节的元素，或者一个结构具有共享存储槽的元素或类型bytesNN小于32字节的成员。
除此之外，在以下情况下，您的代码不受影响：
如果所有结构或数组仅使用uint256或int256类型
如果您只使用整数类型并且一次只编码一个数组
如果您只返回此类数据但不使用abi.encode，在外部调用或事件数据中。
如果您的合约符合这些条件，并且想要验证合约是否确实存在漏洞，您可以通过与我们联系。
如何防止
为了保守起见，实验性ABI编码器只有在明确启用时才可用，允许人们与它进行交互并测试它，而不会在它被认为稳定之前对它过分信任。
我们尽最大努力确保高质量，并且最近开始研究OSS-Fuzz上某些部分的“语义”模糊测试。
对于开发人员-使用漏洞检测器等工具很难检测Solidity编译器中的，因为对源代码或抽象语法树表示进行操作的工具不会检测仅引入编译字节码的缺陷。
防止这些缺陷的最佳方法是为您的合约进行一系列严格的端到端测试，因为编译器中的错误很可能不是“静默”而是表现为无效数据。
危害
当然，根据程序控制流程，任何bug都会产生各种各样的后果，但我们预计这更容易导致故障而不是可利用性。
当bug被触发时，在某些情况下会将方法调用上的错误参数发送到其他合约。
时间线
2019年3月16日：
通过漏洞赏金计划进行报告，关于直接从存储到ABI编码器的布尔数组中读取时所导致的损坏。
2019年03月16日至2019年03月21日：
调查根本原因，分析受影响的合约。在主网上部署了大量使用实验性编码器编译的合约，其中许多合约没有经过一致性校验的源代码。
对bug的调查发现了更多触发bug的方法，例如使用结构。此外，在同一程序中还发现了一个数组溢出错误。
检查了在Github上发现的一些合约，没有发现任何合约受到影响。
对ABI编码器进行了错误修正。
2019年03月20日：
决定公开信息。
推理：检测所有易受攻击的合同并及时与所有作者联系是不可行的，最好防止主网上的不安全合约进一步扩散。
2019年3月26日：
新的编译器版本，版本0.5.7。
这篇文章发布了。
技术细节
背景
合约ABI是一种规范如何与来自外部的合约或合约之间的交互来交换数据的规范。它支持各种类型的数据，包括数字，字节和字符串等简单值，以及更复杂的数据类型，包括数组和结构。
当合同收到输入数据时，它必须解码，并且在返回数据或将数据发送到另一个合同之前，它必须对其进行编码。Solidity编译器为合约中的每个已定义函数生成这两段代码。在Solidity编译器中，生成编码器和解码器的子系统称为“ABI编码器”。
2017年中旬，Solidity团队开始研究名为“ABI编码器V2”的全新实现，目标是提供更灵活，安全，高性能和可审计的代码生成器。这个实验性代码生成器在明确启用后，自2017年底开始向用户提供0.4.19版本。
缺陷
实验性ABI编码器不能正确处理短于32个字节的非整数值。这适用于bytesNN类型，bool，enum和其它类型的，当它们是数组或结构的一部分并直接从存储中编码时。这意味着这些存储引用必须直接在内部使用abi.encode(...)，作为外部函数调用或事件数据中的参数，而无需事先分配给局部变量。使用return不会触发错误。类型bytesNN和bool将导致数据损坏，但enum可能导致无效revert。
此外，即使基础类型是整数类型，也可能无法正确处理元素短于32字节的数组。如果编码的元素数量不是适合单个存储槽的元素数量的倍数，那么按照上面描述的方式编码这样的数组会导致编码中的其他数据被覆盖。如果编码中的数组后面没有任何内容，或者如果只编码单个数组，则不会覆盖其他数据。
两个无关的bug
与上面解释的ABI编码器问题无关，在优化器中发现了两个错误。两者都引入了0.5.5。除非使用内联汇编，否则它们不太可能出现在编译器生成的代码中。
通过最近为OSS-Fuzz添加Solidity来识别这两个错误-这是一个用于查找各种项目中的差异或问题的安全工具包。对于Solidity，我们已经包含了多个不同的模糊测试器，用于测试编译器的不同方面。
优化器将操作码序列转换((x<<a)<<b))转换为(x<<(ab))时不会正确处理加法中的溢出。
如果将常量31用作第二个参数，则优化器会错误地处理byte操作码。在对bytesNN编译时常量值为31的类型执行索引访问或在内联汇编中使用字节操作码时，可能会发生这种情况。
这篇文章由@axic，@chriseth，@holiman联合撰写
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。