Десятилетняя ошибка в реестре XRP могла создать XRP из ниоткуда

Что на самом деле не работало?

Проблема заключалась в коде, отвечающем за расчет платежей на встроенной децентрализованной бирже (DEX) $XRP Ledger. Согласно официальному отчету о раскрытии уязвимости, опубликованному вчера, когда один платеж охватывал множество предложений, механизм суммировал суммы с использованием непроверенной 64-битной арифметики.

При достаточно большом увеличении этой суммы происходил «перенос», то есть переполнение целого числа. Гигантское число впоследствии превращалось в маленькое, и продавцы на другой стороне сделки получали полную оплату, но с покупателя списывалась только «перенесенная», крошечная сумма. Разница представляла собой $XRP, которых ранее не существовало.

В реестре действительно выполняется проверка безопасности, известная как «инвариант», которая должна подтверждать, что $XRP никогда не создаётся. Эта проверка использовала ту же непроверенную математику, поэтому она не смогла обнаружить именно ту ошибку, для выявления которой и была создана. В отчёте указывается, что источником уязвимости является текущий платежный движок, написанный в 2015 году.

Насколько дешевой была бы такая атака?

Согласно отчету, затраты составили несколько сотен $XRP, заблокированных в качестве резервов (которые возвращаются после удаления объектов), плюс обычные комиссии за транзакции. Злоумышленнику потребовалось бы разместить сотни предложений с намеренно заниженной ценой, а затем пропустить через них один платеж.

Самым пугающим был потенциальный ущерб: в RippleX назвали эту ошибку критической, поскольку в рамках одной подтвержденной транзакции могло быть создано количество $XRP, превышающее общий объем предложения. Вся концепция $XRP основана на жестком ограничении в 100 миллиардов токенов, поэтому незаметное создание новых токенов подорвало бы основное обещание актива. Именно поэтому в таких публикациях, как пост от Whale Insider, эту уязвимость описывали как ошибку, которая могла бы привести к появлению «миллиардов» $XRP.

Кто обнаружил ошибку и как быстро её устранили?

Хронология событий была довольно краткой и выглядела следующим образом:

• 22 сентября: Кейден Ляо и Veria AI представили свои выводы через программу XRPL Bug Bounty, присвоив им уровень «Major».
• 23 сентября: RippleX воспроизвела ошибку, повысила её уровень до «критического», и исправление было внедрено.
• 25 сентября: была выпущена версия Xrpld 3.4.1, и в тот же день на ней работали более 80% валидаторов из списка уникальных узлов (UNL) по умолчанию.
• 9 октября: публичное раскрытие информации.

Патч не прошел обычное голосование по поправкам, а был выпущен в виде прямого изменения кода в версии 3.4.1 и вступил в силу по мере обновления каждого сервера. Исходный код был опубликован только после развертывания — это стандартный шаг, призванный не дать злоумышленникам «карту». С тех пор аккаунт XRPL Operations установил версию 3.4.1 в качестве минимально требуемой, добавив:

Мы не обнаружили никаких доказательств того, что эта уязвимость была использована в какой-либо публичной сети.

В том же релизе была исправлена вторая уязвимость, имеющая более низкий уровень серьезности. Она касалась способа формирования пакетных транзакций, и её исправление реализовано в поправке fixBatchV1_2, которая была запущена в Mainnet 9 октября одновременно с BatchV1_1. В отчёте указано, что в результате этой уязвимости средства также не были утрачены.

Это сообщение появилось в неблагоприятную для криптовалютной безопасности неделю, поскольку убытки от потери устройств Ledger, о которых сообщал Bitcoin.com News, достигли, по оценкам, 93,4 млн долларов. Наконец, компания Evernorth, поддерживаемая Ripple, готовится в понедельник начать торги на Nasdaq под тикером XRPN, имея на счетах примерно 473 млн $XRP. $XRP также расширяет своё присутствие в сфере децентрализованных финансов (DeFi): недавно Firelight активировала в сети функцию защиты хранилища.