Директор по инженерии Ripple Виджай Кханна 2 августа призвал операторов узлов XRP Ledger установить версию xrpld 3.2.1 после того, как разработчики наблюдали наводнение манифестов валидаторов 31 июля.
Резюме
- Наводнение манифестов 31 июля побудило выпустить xrpld 3.2.1, в то время как XRP Ledger продолжал нормально закрывать реестры на протяжении всего инцидента.
- Четыре защитных механизма теперь ограничивают размер манифеста, пакеты сообщений, исходящий обмен и рост кэша неизвестных ключей в масштабе всей сети.
- Операторам следует обновиться, проверить, что xrpld работает, а затем перезапустить его снова, чтобы безопасно очистить сохраненные манифесты.
Исправление ограничивает то, как узлы обрабатывают, хранят и передают данные, полученные от неизвестных идентификаторов валидаторов.
XRP Ledger продолжал нормально закрывать реестры во время события, согласно XRP Ledger Operations. Поэтому имеющиеся доказательства указывают на давление на ресурсы узлов и пиринговые коммуникации, а не на подтвержденную потерю средств, измененные транзакции или сбой консенсуса реестра. Разработчики не публиковали идентификатор CVE или оценку финансовых потерь, связанных с инцидентом.
XRPL 3.2.1 ограничивает путь наводнения манифестов
Манифесты валидаторов — это криптографически подписанные записи, которые связывают стабильную основную идентичность валидатора с временным ключом, используемым им для ежедневных сообщений валидации. Когда операторы меняют эти временные ключи, они публикуют новый манифест, подписанный основным ключом, чтобы другие узлы могли проверить изменение.
До исправления узлы могли принимать, кэшировать и ретранслировать корректно структурированные манифесты, связанные с ключами валидаторов, которые они не распознавали. Злоумышленник мог использовать это поведение, создавая множество неизвестных идентичностей и заставляя пиров тратить память, хранилище, пропускную способность и вычислительную мощность на обработку данных. Публичная запись кода описывает этот недостаток как проблему с распространением манифестов.
Официальный выпуск xrpld 3.2.1 датирован 31 июля и был опубликован как последний подписанный выпуск рано утром 1 августа. Он содержит шесть коммитов в 13 измененных файлах, включая четыре коммита, которые напрямую ограничивают обработку ненадежных манифестов.
Четыре защитных механизма снижают риск истощения ресурсов
Первый защитный механизм отклоняет манифест валидатора слишком большого размера до того, как узел полностью его декодирует. Это уменьшает объем вычислительной работы, которую злоумышленник может вызвать, отправляя отдельные объекты большего размера, чем ожидает программное обеспечение.
Второй ограничивает количество ненадежных манифестов в одном сетевом сообщении. Ограничение применяется, когда узлы получают данные и когда они готовят сообщения манифестов для пиров. Пакеты слишком большого размера отбрасываются без автоматического отключения незапатентованного пира, что помогает обновленным и старым узлам оставаться подключенными во время развертывания.
Третье изменение ограничивает количество неизвестных идентификаторов валидаторов, хранящихся в кэше манифестов узла. Финальный код устанавливает максимум 100. После достижения этой емкости программное обеспечение отклоняет манифесты, связанные с новыми не включенными в список ключами, продолжая обрабатывать доверенных или ранее распознанных валидаторов.
Патч также изменяет способ хранения и распространения информации о ненадежных манифестах. Данные доверенных валидаторов остаются доступными, поскольку ограничения нацелены на непроверенные слухи пиров, а не на манифесты от настроенных или одобренных валидаторов. Это различие позволяет нормальной ротации ключей валидаторов продолжаться, блокируя неконтролируемый рост кэша.
Операторам узлов необходимо выполнить второй перезапуск
Кханна посоветовал валидаторам и другим операторам инфраструктуры обновиться до версии 3.2.1 «как можно скорее». Его инструкции предусматривают обычное обновление программного обеспечения, затем ожидание в течение одной-двух минут и проверку того, что xrpld работает. Затем операторам следует перезапустить службу снова.
Второй перезапуск важен для узлов, которые могли сохранить неизвестные манифесты до установки исправления. Обновление изменяет дальнейшую обработку, а перезапуск исправленного сервера помогает гарантировать, что старые данные в памяти или ранее сохраненные данные не продолжат влиять на операции.
Операторам также может потребоваться подтвердить, что их системы доверяют текущему ключу подписи пакетов Ripple. В примечаниях к выпуску указано, что Ripple сменила ключ GPG, используемый для подписи пакетов xrpld, 18 февраля. Существующие установки, которые не доверяют заменяющему ключу, могут не получать автоматические обновления успешно.
Обновление относится к поставщикам инфраструктуры, а не к обычным держателям XRP. Пользователям не нужно перемещать XRP, менять ключи кошелька или создавать новые учетные записи из-за проблемы с манифестами. Биржи, кастодианы, бэкенды кошельков, поставщики данных и предприятия, которые запускают собственные серверы XRPL, должны вместо этого подтвердить версии своих узлов и статус перезапуска.
Посмертный анализ определит масштаб инцидента
XRP Ledger Operations сообщила, что технический «посмертный анализ последует в ближайшее время». По состоянию на 2 августа проект не опубликовал этот отчет, поэтому личность отправителя, объем переданных манифестов и точное использование ресурсов на затронутых узлах остаются нераскрытыми.
Отчет также должен прояснить, когда разработчики впервые обнаружили активность, были ли какие-либо узлы недоступны и как быстро операторы приняли версию 3.2.1. Хотя реестры продолжали закрываться, медленное внедрение исправлений может оставить отдельные серверы подверженными повторному flooding, даже если общий реестр остается работоспособным.
Горячее исправление появляется вскоре после более крупного развертывания версии 3.2.0 XRPL. Этот выпуск, выпущенный 15 июня, переименовал эталонный сервер с rippled на xrpld и внес изменения в инфраструктуру, которые потребовали от операторов обновить программное обеспечение и конфигурации служб.
Как ранее сообщалось, версия 3.2.0 изначально распространялась быстрее среди валидаторов, чем по более широкой сети узлов. Наводнение манифестов добавляет новую причину для оставшихся операторов перейти с этого выпуска и установить горячее исправление.
Тем временем, в связанном освещении, Дэвид Шварц перевел свою инфраструктуру XRPL на версию 3.2.0, пока разработчики готовили сеть к новому именованию серверов и функциям протокола. Ранее, как сообщал crypto.news, операторы узлов также столкнулись с крайним сроком версии 3.1.3, связанным с активацией поправки.
Следующими проверенными обновлениями будут обещанный посмертный анализ и свежие данные о внедрении программного обеспечения. До тех пор подтвержденный ответ ограничивается выпуском 3.2.1, его четырьмя элементами управления манифестами и просьбой к операторам завершить процесс обновления и перезапуска.
