Десятилетняя ошибка в реестре 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 активировала в сети функцию защиты хранилища.