注意安全风险
作者：Beosin
封面：Ronin
8 月 6 日，据区块链安全审计公司 Beosin Alert 监测显示，Ronin Bridge 项目出现异常提取跨链资产的行为。据 Beosin 安全团队分析，此次异常行为的根本原因在于项目方升级合约时，未正常初始化配置跨链交易确认所需的 operator 权重，导致合约中的 minimumVoteWeight 参数为零，从而使得任何人的签名都能通过跨链验证。
攻击交易链接：
https://etherscan.io/tx/0x2619570088683e6cc3a38d93c3d98899e5783864e15525d5f5810c11189ba6cb
Beosin 目前正与项目方合作处理此次事件，本篇长文，我们也将与大家分析本笔交易存在异常的点在于两点：
首先，提取数量过高。在 Ronin Bridge 中，有跨链提取额度的限制，如果跨链提取的额度太大，则需要转至人工确认，而本次交易的跨链资产 WETH 的限制额度为 4000。此笔交易提取了 3996 个。当然这不是漏洞，但足以让人引起了注意。
其次，查看这笔提取交易发现，其跨链验证者 Operator 只有一个，且对应的操作权重为 0，那就可以确认这笔交易是存在问题的，因为在 Ronin Bridge 项目中，用户提取跨链资产需要得到多个 Operator 的签名，且累计的权重必须达到指定阈值。
事件分析：
分析链上合约和数据发现，合约 Operator 是对应的 Manager 合约独立管理，并且它是一个治理合约，专门用于管理 ronin bridge，查看其交易记录，发现最近一笔交易是对 Ronin Bridge 合约进行升级，并且就在异常交易之前。所以漏洞的大致方面就基本明确，应该是项目方升级合约所导致的问题。
进一步深入，对比 Ronin Bridge 升级前后的代码发现，事件所使用的关键参数 “_totalOperatorWeight” 是本次升级新增的，并且需要在升级中调用 initializeV3 函数进行 V3 版本新增的 “OperatorWeight” 进行初始化。
但遗憾的是：升级合约的交易中，并未调用 initializeV3 函数，而是错误调用 initializeV4 函数进行了 V4 版本的初始化。
至此，该事件的漏洞原理已经明了，Ronin Bridge 项目方在合约升级时未正确对新增数据进行初始化，导致对应的关键数据 “_totalOperatorWeight” 始终为 0，使得任意用户的提取请求都可以通过审核。
至本文发布前，项目方已经确认该问题，并发文说了本次攻击行为是白帽所为，并已进行退款，并未造成过多的损失。这是一个好消息，但是也暴露了合约升级这一大易出错的点。
可升级合约
可升级合约是一种 solidity 智能合约设计方案，使得已部署的合约能够在未来进行升级或修改，而无需完全重新部署。这个概念的核心在于将合约的逻辑和数据分离，并利用 “delegatecall” 实现对逻辑合约的调用。
尽管这种模式提供了灵活的升级能力，我们也必须高度重视其安全性。由于代理合约负责转发所有的用户请求，它实际上成为了合约系统的入口点。任何对代理合约的攻击都可能影响到整个合约的安全性。因此，在设计和部署可升级合约时，确保代理模式的安全性至关重要。目前代理模式的合约需要注意以下几点：
函数选择器冲突
在以太坊虚拟机（EVM）中，每个智能合约函数都有一个唯一的标识符，称为函数选择器。这个选择器是函数签名的前 4 个字节的哈希值。函数选择器用于确定合约中的具体函数，确保调用请求被正确路由到相应的函数实现。而在代理模式在调用函数时，会先检查代理合约中的函数接口是否能匹配调用函数，如果不能匹配，才会利用 fallback 中的 delegatecall 调用逻辑合约。
因此，如果代理合约和逻辑合约中存在函数选择器相同的函数，当代理合约接收到调用时，它直接调用代理合约中的函数，而不是逻辑合约，这可能导致预期之外的行为或安全漏洞。
存储冲突
在以太坊虚拟机（EVM）中，合约的状态数据存储在特定的存储槽中，每个存储槽的地址由其索引（从 0 开始）确定。合约中的每个状态变量都对应一个存储槽，数据在这些槽中持久化。
在代理模式中，存储槽通常是由代理合约管理的，而逻辑合约则通过代理合约来访问这些槽。存储冲突可能发生在逻辑合约中新增的状态变量与代理合约中现有的状态变量槽发生冲突时。这可能导致代理合约中的数据被覆盖或不一致
合约初始化问题
在代理模式中，由于代理合约和逻辑合约的分离，而每次升级可能都涉及到变量的更改和新增，因此在升级时必须确保在正确设置这些关键变量。本次的 ronin bridge 事件就是因为这个问题没做好，导致被攻击。
此外，需要确保初始化函数 initialize 只能被调用一次，以防止在初始化后被恶意攻击者重复调用，从而修改关键变量。
ldelegatecall 调用机制
delegatecall 是一种低级调用机制，它允许一个合约在其上下文中执行另一个合约的代码。这意味着，调用合约的存储、地址和消息发送者保持不变，但执行的逻辑来自被调用的目标合约。虽 delegatecall 提供了强大的功能，但也需要谨慎使用。
如果目标合约地址不存在，delegatecall 的执行将失败并返回失败码，但这种失败可能不会被立刻发现。结果，代理合约中的调用可能看起来像是成功，但实际操作并未生效，从而导致系统的不一致或错误。
代理合约权限管理
在代理模式中，权限管理是另一个关键的安全问题。代理模式通过分离代理合约和逻辑合约的职责，使得合约可以在不改变数据存储的情况下进行升级，但同时也引入了复杂的权限管理问题。正确地管理权限对于保证合约系统的安全性和稳定性至关重要。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
