Директор з інженерії 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. Хоча реєстри продовжували закриватися, повільне впровадження виправлень може залишити окремі сервери вразливими до повторного затоплення, навіть якщо спільний реєстр залишається робочим.
Гаряче виправлення з'являється незабаром після більшого розгортання версії 3.2.0 XRPL. Цей випуск, опублікований 15 червня, перейменував еталонний сервер з rippled на xrpld і вніс зміни в інфраструктуру, які вимагали від операторів оновлення програмного забезпечення та конфігурацій сервісів.
Як раніше повідомлялося, версія 3.2.0 спочатку поширювалася швидше серед валідаторів, ніж по всій мережі вузлів. Затоплення маніфестами додає нову причину для операторів, що залишилися, перейти з цього випуску та встановити гаряче виправлення.
Тим часом, у відповідному висвітленні, Девід Шварц перевів свою інфраструктуру XRPL на версію 3.2.0, оскільки розробники готували мережу до нового найменування серверів і функцій протоколу. Раніше, як повідомляв crypto.news, оператори вузлів також стикалися з дедлайном версії 3.1.3, пов'язаним з активацією поправки.
Наступними підтвердженими оновленнями будуть обіцяний пост-мортем і свіжі дані про впровадження програмного забезпечення. До того часу підтверджена відповідь обмежується випуском 3.2.1, його чотирма контролю маніфестів та вимогою до операторів завершити оновлення та перезапуск.
