XRP Ledger修复了2015年可能引发……的漏洞

XRP Ledger fixes a ten-year-old bug: Prevents attackers from creating expendable XRP out of thin air

XRP Ledger (XRPL) fixes a ten-year-old software bug. If exploited, the vulnerability could allow attackers to create expendable XRPs without providing funds, thereby bypassing one of the network's most basic monetary rules: that the total number of XRPs should not exceed the original 100 billion.

On September 22, researchers Cayden Liao and Veria AI reported the vulnerability through the XRPL Vulnerability Bounty Program. RippleX engineers replicated the attack that day, confirmed that the newly created XRP could be spent in subsequent transactions, and raised the severity of the problem from "major" to "critical." The fix was released on September 25 with xrpld version 3.4.1. It was not until October 9 that full details of the vulnerability were disclosed to the public. According to the XRP Ledger Disclosure Report, developers "found no evidence that the issue was exploited on any public network."

Hundreds of quotes and one payment can create a new XRP

This flaw lies in XRP Ledger's payment engine and its built-in decentralized exchanges. Attackers could create hundreds of accounts and have each account issue a quote, exchanging extremely small amounts of other tokens for an unusually large amount of XRP. Each individual quote is valid in itself. An attacker can then send a specially constructed payment transaction that consumes all of these quotes at once.

The problem arises when the payment engine calculates the total amount of XRP due from the buyer. The XRP amount is accumulated using a 64-bit integer. When the cumulative value exceeds the maximum range that the integer can hold, the value overflows and wraps around to a very small value rather than an error. At this point, the engine still credits the seller with XRP at the full amount specified in each quote, but only charges the buyer the total amount after the overflow. The difference is XRP that did not exist before.

RippleX pointed out that the attack did not require the attacker to have assets close to the amount created. The actual upfront cost only requires a few hundred XRPs for account and quote reserves, most of which can be recovered after the ledger objects are removed, plus ordinary transaction fees. Moreover, the attack cannot happen accidentally; it requires hundreds of deliberately mispriced quotes and a payment transaction specifically constructed to consume them at the same time.

Security checks may also fail to detect casting behavior

What is even more unusual about this vulnerability is that XRP Ledger originally has a security mechanism designed to prevent transactions from creating XRP. However, this invariant does not solve the problem. Post-trade checks use the same 64-bit arithmetic to calculate net XRP balance changes. If the calculations of the payment engine overflow, security checks may overflow in the same way. As a result, the results could show that XRPs destroyed or created during the transaction were only normal transaction fees, despite hundreds of accounts controlled by the attacker receiving new XRPs.

另一项保护措施也未能封闭这一路径。账本会拒绝单个账户持有量超过 XRP 总供应量的情况。通过将新创造的 XRP 分散到数百个账户中，攻击者可以使每个账户的余额低于该限制。XRPL 的调查表明，底层的溢出问题自 2015 年当前支付引擎编写以来便已存在。“不创造 XRP”的不变量大约在两年后添加，但继承了相同的算术弱点。

9 月 25 日修复，10 月 9 日公开解释

披露文件还解释了为何 9 月 25 日的版本为运营商提供的安装细节极少。3.4.1 版本作为紧急版本发布，旨在解决“敏感安全问题”。其公开更新日志仅提及“支付引擎和账本辅助工具中的各类整数算术加固”，并未披露底层漏洞可能铸造可花费的 XRP。包含修复方案的源代码也被暂时扣留。RippleX 表示这是故意的。如果在正常的两周修正案流程仍在运行时发布补丁，可能会让攻击者精确知道漏洞所在，而此时大部分网络仍处于脆弱状态。因此，溢出修正并未经过正常的修正案流程，而是在服务器安装 3.4.1 后立即生效。XRPL 称，这是十多年来首次以这种方式有意部署的交易处理变更。据披露文件显示，截至 9 月 25 日，默认唯一节点列表（UNL）上超过 80% 的验证器已升级至 3.4.1。在网络得到保护后，完整的技术报告和源代码才公开。

This emergency release attracted attention before it was disclosed. Previous reports pointed out that after the introduction of security fixes in xrpld 3.4.1, the validator reset the batch activation schedule of XRP Ledger, postponing the upgrade from September 29 to October 9. When preparing for new software, the validator also tracks authority delegation and the corresponding October 8-9 amendment schedule.

Node operators should upgrade to xrpld 3.4.1 or later

When the server installs xrpld 3.4.1, the overflow issue is immediately fixed. At the same time, the BatchV1_2 amendment included in the same emergency version went online on the main network on October 9. This means that carriers that are still running older versions are now blocked by the amendment and cannot continue to synchronize with the network. XRPL's current instructions are to use version 3.4.1 or later for all server operators.

XRP's fixed supply rules themselves have not changed. The XRP Ledger document states that all 100 billion XRPs were created at the launch of the network in 2012, and no additional XRPs should be created under the agreement. The significance of the vulnerability discovered in September is that for about a decade, there is a way to circumvent the rule that can be deliberately exploited-and the inspection mechanism used by the ledger itself to detect newly created XRP may also commit the same arithmetic errors as the vulnerability transaction.