Команда разработчиков XRP Ledger (XRPL) раскрыла 9 октября уязвимость целочисленного переполнения, которая при тщательно подготовленных условиях могла позволить создать расходуемые XRP из ничего. Исправление вышло в составе xrpld версии 3.4.1 25 сентября, примерно за две недели до публичного раскрытия, и команда сообщила об отсутствии признаков того, что уязвимость когда-либо эксплуатировалась в публичной сети.

Подробности изложены в отчете о раскрытии уязвимостей от 9 октября.

Расчет платежа, который мог создать XRP из ничего

В отчете описывается уязвимость целочисленного переполнения в платежном движке реестра. При тщательно подготовленных условиях платеж, потреблявший множество ордеров из книги заявок, мог зачислить на счета XRP, которые отправитель фактически не оплачивал. Книги заявок — нативная структура XRPL, часть встроенной биржи реестра, поэтому ошибочная арифметика находилась в коде, лежащем в основе как торговли в реестре, так и платежей.

Каждый отдельный ордер в транзакции мог выглядеть корректным сам по себе. Сбой возникал, когда движок суммировал суммы XRP по всем ордерам. Как только итог превышал максимальный размер числа, используемого для этого расчета, значение могло переполниться до гораздо меньшего вместо ошибки.

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

Почему уязвимость была серьезной

Атака не требовала крупного баланса XRP. Атакующий мог контролировать счета, размещавшие ордера, оплатить необходимые резервы счетов и комиссии за транзакции, а затем распределить созданные XRP между этими счетами.

Уязвимость находилась в платежной арифметике, а не в доступе к кошелькам, поэтому ключи счетов оставались незатронутыми. Для ее срабатывания требовались сотни ордеров со специально подобранными ценами и транзакция, предназначенная для их совместного потребления; обычный платеж или торговая операция в XRP не приближалась к значениям, необходимым для переполнения.

Для реестра мало какие дефекты так же чувствительны, как тот, который может создать расходуемые единицы, поскольку каждый баланс зависит от того, что новые XRP попадают в обращение только согласно определенным правилам сети.

XRPL сообщила, что не обнаружила признаков эксплуатации в публичной сети, и не было зафиксировано компрометации приватных ключей, потери средств или сбоя консенсуса. Судя по всему, уязвимость существовала с момента написания текущего платежного движка в 2015 году и оставалась необнаруженной, поскольку обычная активность никогда не достигала арифметического предела.

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

Почему разработчики применили экстренное развертывание

Разработчики выпустили исправление до публикации его технических деталей, поскольку стандартный график внесения поправок оставил бы известную уязвимость доступной в течение недель. Патч вышел в составе xrpld версии 3.4.1 25 сентября, а публичное раскрытие состоялось 9 октября.

XRPL обычно изменяет правила транзакций путем внесения поправок (amendments). Валидаторы сначала обновляют свое ПО, затем поддерживают необходимое одобрение в течение установленного периода, после чего новое правило активируется в одной и той же точке реестра по всей сети. Этот процесс позволяет избежать ситуаций, когда разные серверы приходят к разным выводам об одной и той же транзакции.

В данном случае ожидание этого процесса создало быную проблему. Поскольку xrpld является open source, публикация исправления могла бы показать атакующим, где искать, пока устаревшее ПО все еще принимало уязвимый путь транзакции. Поэтому команда сделала новую проверку переполнения действующей при обновлении отдельного сервера.

Этот более быстрый подход нес временный риск совместимости: необновленный сервер мог принять эксплойт-транзакцию, которую обновленный сервер отклонил бы. Разработчики сочли это менее опасным, чем допуск созданных XRP на рынок. Согласно отчету, более 80% валидаторов из стандартного UNL обновились в день выхода версии 3.4.1.

Раскрытие затронуло второй, отдельный недостаток

В отчете также описана проблема валидации в будущей функции Batch для XRPL, позволяющей пользователям отправлять несколько транзакций как единое целое. Этот недостаток мог привести к тому, что серверы с разными версиями ПО по-разному трактовали некорректную Batch-транзакцию, прерывая валидацию реестра или ломая приложения, анализирующие данные транзакций.

Недостаток Batch был обнаружен до того, как функция достигла mainnet. Проблема переполнения, напротив, затрагивала существующий код платежного движка, поэтому ее патч не мог ждать стандартного цикла активации. Поскольку сама функция еще не вышла, ее появление в mainnet с уже установленным исправлением валидации — та часть раскрытия, которая еще впереди.

Отчет был опубликован в то время, когда XRPL также активировала новые инструменты управления счетами для бизнеса. Эти изменения затрагивают разные части реестра, однако оба зависят от того, что операторы узлов, провайдеры кошельков и разработчики следуют одним и тем же актуальным правилам.

Что должны делать пользователи и операторы

Обычным держателям XRP не нужно перемещать средства, менять кошелек или обменивать токены. Обновление касается ПО, валидирующего транзакции, а не балансов счетов, ключей кошельков или запаса XRP у пользователей.

• Держатели XRP: никаких действий не требуется.
• Пользователи бирж: следите за уведомлениями платформы, если биржа проводит обслуживание собственной инфраструктуры XRPL.
• Операторы узлов: обновитесь до xrpld 3.4.1 или новее, чтобы оставаться синхронизированными с сетью. Устаревшие серверы теперь заблокированы поправками после активации исправления Batch, то есть они не могут продолжать следовать текущим правилам реестра, пока не обновятся.

Исправление защитило правила эмиссии XRP до того, как они были проверены

Раскрытие показывает, как близко реестр подошел к сбою целостности эмиссии и почему валидаторы действовали быстро. Недостаток был исправлен до того, как его детали сталиными, эксплойт не был обнаружен, а платежный движок теперь использует проверки, призванные предотвратить тот же класс арифметических ошибок до того, как они достигнут валидированного реестра. Со стороны остается наблюдать, как быстро остальная часть сети перейдет на xrpld 3.4.1 или новее, учитывая, что необновленные серверы уже заблокированы поправками и не могут следовать текущему состоянию реестра.

Эта статья носит исключительно информационный характер и не является инвестиционной или технической консультацией. Операторам узлов следует ознакомиться с актуальной документацией релизов XRPL перед обновлением производственной инфраструктуры.

Эта статья основана на материале, впервые опубликованном Coindoo.