Недавнее исследование выявило серьезную уязвимость в предложенном обновлении XRP Ledger (XRPL), которая могла бы позволить несанкционированные транзакции. Однако исследователи обнаружили эту проблему до того, как она могла попасть в основную сеть блокчейна. Фонд XRPL сообщил 26 февраля, что уязвимость была найдена в предложенной поправке «Batch», предназначенной для того, чтобы позволить пользователям объединять несколько действий в одну атомарную транзакцию.
Обнаружение уязвимости
Исследователь в области безопасности Пранамья Кешкамат и автономный инструмент статического анализа Cantina AI, Apex, сообщили о проблеме 19 февраля, согласно данным фонда. Если бы поправка была активирована с этой ошибкой, злоумышленник мог бы выполнять внутренние транзакции так, как будто они были авторизованы другим аккаунтом, не имея доступа к приватным ключам этого пользователя. Это могло бы привести к несанкционированным переводам средств и изменениям в настройках книги учета под аккаунтом жертвы, даже если жертва не подписала транзакцию.
Проблемы с авторизацией
Предложенная поправка Batch изменила способ авторизации в XRP Ledger, позволяя объединять несколько «внутренних» транзакций в одну «внешнюю» транзакцию Batch, так что все шаги либо успешно выполняются, либо отклоняются вместе. Эта атомарная структура может снизить риск выполнения для разработчиков, осуществляющих многоступенчатые операции. Однако она также создает новую границу авторизации.
В дизайне Batch внутренние транзакции намеренно не подписываются. Вместо этого полномочия делегируются списку подписантов, прикрепленных к внешней транзакции, что делает код проверки подписчиков критической контрольной точкой. Если эти проверки не проходят, книга учета может рассматривать несанкционированные действия как действительные.
Согласно раскрытию информации, ошибка возникла из-за ошибки в цикле в функции, которая проверяет подписчиков пакета. Когда код сталкивался с подписчиком, чей аккаунт еще не существовал в книге учета и чей ключ подписи совпадал с тем же аккаунтом, это нормальное состояние для вновь созданного аккаунта, он немедленно возвращал успех и прекращал проверку остальной части списка подписчиков.
Последствия уязвимости
Это условие было более опасным в системе пакетирования, чем может показаться на первый взгляд. Пакет может включать шаги, которые создают аккаунты внутри одной атомарной последовательности, что означает, что существование аккаунта на момент проверки становится частью границы авторизации. В отчете говорилось, что злоумышленник мог вставить действительную запись подписчика для еще не созданного аккаунта, которым он управлял, вызвать условие преждевременного успеха и обойти проверку подделанной записи подписчика, утверждающей авторизацию аккаунта жертвы.
Если бы Batch был активирован до того, как ошибка была обнаружена, последствия могли бы быть серьезными. Фонд заявил, что злоумышленник мог бы выполнить внутренние транзакции, которые истощили бы аккаунты жертв до резерва. Та же ошибка также могла бы позволить несанкционированные операции на уровне аккаунта, включая AccountSet, TrustSet и потенциально AccountDelete. Это привело бы к сценарию «расходов без ключей», что является типом сбоя безопасности, который может нанести репутационный ущерб, даже если потери будут ограничены и быстро устранены.
Как XRPL предотвратил инцидент
Ответ XRPL на эту ситуацию был быстрым и эффективным. Уникальный список узлов (UNL) доверенных валидаторов был уведомлен и рекомендован проголосовать «нет» по поправке Batch. 23 февраля XRPL выпустил версию rippled 3.1.1, экстренное обновление, которое пометило как Batch, так и fixBatchInnerSigs как неподдерживаемые. Это предотвратило голосование валидаторов за поправки или их активацию в сети.
Выпуск был разработан как немедленная мера по сдерживанию, а не как полное исправление. В раскрытии информации четко указывалось, что версия 3.1.1 не включает исправление основной логики. XRPL также запланировал сброс devnet на 3 марта 2026 года, чтобы совпасть с изменением 3.1.1. Этот сброс применяется только к Devnet, а не к основной сети, но показывает, насколько далеко операторы сети пошли, чтобы предотвратить влияние проблемы на активные пути поправок.
Будущее XRPL и новые вызовы
Корректирующая замена, BatchV1_1, уже была реализована и находится на рассмотрении, однако дата выпуска еще не установлена. Согласно раскрытию, полное исправление устраняет преждевременный выход, добавляет дополнительные защитные меры авторизации и сужает область проверки подписания. Отчет также изложил более широкий план безопасности, включая более стандартизированные аудиты с использованием ИИ, расширенные статические проверки для опасных выходов из циклов и обзор аналогичных паттернов в других частях кодовой базы.
Для XRPL результат февраля будет считаться успехом в управлении. Ошибка была обнаружена до активации, валидаторы скоординировались, экстренное обновление заблокировало путь поправки, и средства не были потеряны. Однако история на этом не заканчивается. BatchV1_1 теперь будет оцениваться по двум уровням. Первый — это технический аспект, сможет ли он предоставить преимущества для разработчиков при пакетировании атомарных транзакций без повторного открытия рисков авторизации. Второй — это процедурный аспект, сможет ли система управления и инженерии XRPL идти в ногу с расширяющимся набором функций, направленных на институциональное принятие.
Заключение
XRPL стремится развиваться в более широкую финансовую платформу, которая может поддерживать закрытые торговые площадки, разрешенные среды и более сложную логику транзакций, привлекая при этом разработчиков с капиталом экосистемы и разнообразием продуктов. Чем более амбициозным становится этот план, тем важнее становятся такие, казалось бы, рутинные вещи, как проверка подписчиков и поведение циклов. В данном случае меры предосторожности сработали, и следующий вызов заключается в том, чтобы доказать, что система может снова ускориться, не теряя этот запас безопасности.
