本文由BlockWeeks编译整理
Ostium 平台被攻击者利用，约2400万美元 USDC 被盗，涉及八笔交易。攻击者通过同时持有授权 oracles 签名密钥和 PriceUpKeep 前置者角色，提交未来日期的正确签名价格报告，并反复开启和关闭交易对，从而制造虚假盈利，实际上没有任何真实的市场敞口。
该攻击发生在八笔交易中，每笔资金均转移至同一钱包 0x321Df1…8bfD9，其中最大单笔转账是在一个原子批次中执行的循环开仓-平仓操作。Ostium 运行于 Arbitrum 上，允许用户交易以远期合约形式交易衍生品，这些合约跟踪底层资产价格，但不存在底层资产交付或固定到期日。
问题源于 Ostium 的或acles 系统如何授权价格数据。验证器接收价格报告，从签名中推导签名者身份，并检查签名者是否在授权列表中。它仅验证签名者的身份，而非价格本身的准确性。攻击者同时持有授权 oracles 签名密钥和注册的 PriceUpKeep 前置者角色（负责履行待处理订单），利用这一组合提交未来日期的正确签名价格报告，然后反复开启和关闭与之对冲的交易对。这使得他们能够从系统视角看来产生交易利润，却没有任何真实的市场敞口。
Ostium 事件是今年多起重大应用层漏洞之一，包括 Drift 和 KelpDAO 的 rsETH 案例。一个共同主题是智能合约及其逻辑依然稳健，攻击者主要目标是操作基础设施和人类信任——在 Ostium 案例中，是被篡改的签名者凭证，在 Drift 案例中，是社会工程学的预签名管理员接管，以及在 KelpDAO 案例中，是毒化的 RPC 基础设施。
在这些高调漏洞之后，一些人呼吁在应用层对用户资金设置保障措施，如限制提现，以威慑恶意行为并限制漏洞发生时的损失。此类建议应予抵制。
限制提现会引入直接的应用层审查风险。一旦协议可以单方面延迟或限制用户存款或提现，该应用层的自我托管概念将不再绝对，而是条件性的。在这种情况下，决定资金可用性和使用方式的是应用，而非用户。这种做法还会模糊攻击者与普通用户之间的界限，因为为阻止攻击而设计的保障措施必然适用于所有使用该应用的用户。
“滑坡效应”风险进一步加剧了这一问题。一旦协议在技术上具备限制或冻结存款/提现的能力，这种能力就会成为先例。监管机构可以引用此作为证据，证明这些应用已经具备满足冻结命令、KYC 门禁或其他要求的工具，因此也应当被强制要求。为阻止攻击而构建的保障措施可能会变成一种钩子，将协议拉向它们否则无法承担的义务。
此外，无辜的市场参与者也会被激励绕过因此措施带来的摩擦。例如，受限用户寻找退出经济暴露的方式通常意味着出现一种可交易的索赔对象来填补缺口（如收据代币、IOU、加密货币的包装替代品）。这项索赔本身就成为新的依赖关系，具有自身的风险面——在市场层面（可能破裂的锚定、恐慌期间折价扩大）和技术层面（新合约、新或acles、新独立于应用的可被利用实体）。原本旨在遏制单点故障的保障措施最终会加剧它试图预防的脆弱性。
此类内容并不意味着协议不应加强那些确实失败的地方（例如签名密钥管理、验证器冗余）。但修复运营基础设施和人类信任的弱点的方法是加强这些方面，而不是增加对用户资金的任意控制，这些控制会削弱被保护事物的核心价值主张。
