Публікація XRPL виправляє критичну ваду перед запуском у mainnet, але клієнтські застосунки залишаються під загрозою з'явилася на BitcoinEthereumNews.com.
Валідатори XRP Ledger (XRPL) перевели BatchV1_1 на умовний шлях активації о 14:06:41 UTC 29 вересня, перетворивши майже допущену загрозу безпеці на реальне випробування процесу внесення поправок у мережі та її супутнього програмного забезпечення. 22 вересня xrpldashboard показав, що 30 із 35 довірених валідаторів підтримують поправку, що перевищує відображений поріг у 28 голосів. Більшість уперше з'явилася в реєстрі 15 вересня. Згідно з правилами внесення поправок XRPL, підтримка має залишатися вище 80% протягом двох тижнів. Падіння до 80% або нижче завершує період більшості, тому дата активації залишається умовною. 29 вересня — це перше виробниче випробування того, чи перетворили процес валідаторів XRPL, еталонна реалізація та клієнтська екосистема небезпечну ваду перед запуском у mainnet на придатну для використання інфраструктуру атомарних транзакцій. Міжмережевий екран валідаторів спрацював до mainnet Оригінальна поправка Batch ніколи не активувалася в mainnet XRP Ledger. У лютому дослідники виявили критичну ваду авторизації, коли поправка ще перебувала на стадії голосування, і валідаторам було рекомендовано проголосувати проти неї. Офіційне розкриття вразливості XRPL Labs зазначає, що кошти не були під загрозою. Вада містилася в циклі, який перевіряв облікові записи, що авторизують пакет. Якщо код зустрічав підписувача для щойно створеного облікового запису, чий ключ збігався з цим обліковим записом, він негайно повертав успіх замість того, щоб продовжити перевірку решти підписувачів. Зловмисник міг поставити цього дійсного підписувача першим, а потім додати підроблений запис, який нібито авторизує обліковий запис жертви. Якби поправка набула чинності, неперевірена транзакція жертви могла б виконатися без ключів жертви. Відповідь XRPL відбулася у два етапи. Версія 3.1.1 позначила оригінальні поправки Batch і fixBatchInnerSigs як непідтримувані, заблокувавши їх активацію. Пізніше BatchV1_1 замінила їх переписаним шляхом авторизації та додатковими засобами захисту. Цей епізод був збоєм, виявленим на межі між випуском програмного забезпечення та активацією протоколу. Остаточна специфікація XLS-56 від XRPL Foundation тепер…
