Використання помилки Lightning було етичним вибором

Це редакція думки Шинобі, викладача-самоучки в біткойн-просторі та ведучого біткойн-подкастів, орієнтованого на технології.

Вже вдруге приблизно за місяць btcd/LND скористався помилкою, через яку вони відхилилися від консенсусу щодо Bitcoin Core. Знову Бурак був розробником, який ініціював цю вразливість — цього разу вона була явно навмисною — і знову це була проблема з кодом для аналізу транзакцій біткойн вище консенсусного рівня. Як я обговорював у своєму частина на попередній баг який ініціював Бурак, до Taproot існували обмеження щодо розміру сценарію та свідкових даних у транзакції. З активацією Taproot ці обмеження було знято, залишивши лише обмеження на розмір блоку, щоб обмежити ці частини окремих транзакцій. Проблема з останньою помилкою полягала в тому, що, незважаючи на те, що консенсусний код у btcd було належним чином оновлено, щоб відобразити цю зміну, код, який обробляє однорангову передачу — включаючи аналіз даних перед надсиланням або під час отримання — не оновлювався належним чином. Таким чином, код, який обробляв блоки та транзакції, перш ніж його фактично передали на перевірку для консенсусу, не передав дані, ніколи не передавав їх до логіки перевірки консенсусу, і блок, про який йде мова, не міг бути перевірений.

Цього разу сталося дуже схоже. Іншим обмеженням у одноранговому розділі кодової бази було неправильне застосування обмежень щодо даних-свідків, обмежуючи їх максимум 1/8 розміру блоку на відміну від повного розміру блоку. Бурак створив а угода з даними свідків лише на одну одиницю ваги понад суворе обмеження та знову зупинені вузли btcd і LND на цій висоті блоку. Ця транзакція була нестандартною, а це означає, що, незважаючи на те, що вона цілком дійсна згідно з правилами консенсусу, вона недійсна згідно з політикою mempool за замовчуванням, і тому вузли не будуть передавати її через мережу. Цілком можливо видобути його в блок, але єдиний спосіб зробити це — надати його безпосередньо майнеру, що Бурак і зробив за допомогою F2Pool.

Це дійсно підтверджує те, що будь-який фрагмент коду, метою якого є аналіз і перевірка даних біткойн, повинен пройти ретельний аудит, щоб переконатися, що він відповідає тим, що буде робити Bitcoin Core. Немає значення, чи є цей код механізмом консенсусу для реалізації вузла чи просто частиною коду, що передає транзакції для вузла Lightning. Цей другий баг був буквально прямо над тим, що був минулого місяця у кодовій базі. Його навіть ніхто з Lightning Labs не виявив. AJ Towns повідомив про це 11 жовтня, через два дні після того, як початкову помилку спричинила багатопідписна транзакція Бурака 998 із 999. Він був публічно опублікований на Github протягом 10 годин, а потім був видалений. Потім було зроблено виправлення, але не опубліковано, з наміром тихо виправити проблему в наступному випуску LND.

Зараз це досить стандартна процедура для серйозної вразливості, особливо для такого проекту, як Bitcoin Core, де така вразливість може завдати серйозної шкоди мережі/протоколу базового рівня. Але в цьому конкретному випадку він становив серйозний ризик для коштів користувачів LND, і враховуючи той факт, що він був буквально поруч із попередньою помилкою, яка мала ті самі ризики, шанси, що її знайдуть і використають, були дуже високими, як продемонстрував Бурак. У зв’язку з цим постає питання, чи підхід тихого виправлення є правильним шляхом, коли мова йде про такі вразливості, які можуть зробити користувачів відкритими для крадіжки коштів (оскільки їхній вузол не може виявити старі стани каналу та належним чином покарати їх).

Як я згадував у своїй останній статті про помилку, якби зловмисник знайшов помилки раніше, ніж розробник із добрими намірами, він міг би тактично відкрити нові канали для вразливих вузлів, спрямувати весь вміст цих каналів назад собі, а потім використав помилку. Звідти вони мали б ці кошти під своїм контролем, а також могли б закрити канал у початковому стані, буквально подвоївши свої гроші. Те, що Бурак зробив, активно використовуючи цю проблему в іронічний спосіб, насправді захистило користувачів LND від такої атаки.

Після того, як це було використано, користувачі були відкриті для таких атак з боку попередніх однорангових пристроїв, з якими вони вже мали відкриті канали, але вони більше не могли бути мішенню спеціально для нових каналів. Їхні вузли були заблоковані, і вони ніколи не розпізнавали й не обробляли платежі через канали, які хтось намагався відкрити після блокування, яке зупинило їхній вузол. Отже, хоча це не повністю усунуло ризик експлуатації користувачів, воно обмежило цей ризик для людей, з якими вони вже мали канал. Вчинок Бурака пом'якшив його. Особисто я вважаю, що така дія у відповідь на помилку мала сенс; це обмежило шкоду, повідомило користувачам про ризик і призвело до швидкого виправлення.

LND також постраждав не тільки. Рідина процес прив'язки також був порушений, що потребує оновлень для функціонерів федерації, щоб виправити це. Старіші версії Rust Bitcoin також постраждали, що призвело до того, що зупинка вплинула на деякі дослідники блоків і екземпляри electrs (реалізація серверного сервера для Electrum Wallet). Тепер, за винятком прив’язки Liquid, яка в кінцевому підсумку відкриває кошти для ключів екстреного відновлення, які зберігає Blockstream після закінчення часу блокування — і, реалістично в сюжеті фільму в стилі пограбування, де Blockstream вкрав ці кошти, кожен точно знає, за ким йти — ці інші Проблеми ніколи не піддають чиїсь кошти ризику. Крім того, Rust Bitcoin фактично виправив цю конкретну помилку в новіших версіях, що, вочевидь, не призвело до будь-якого спілкування з розробниками інших кодових баз, щоб висвітлити потенціал таких проблем. Лише активне використання помилки в прямому ефірі в мережі показало, що проблема існує в кількох кодових базах.

Це викликає деякі серйозні проблеми, коли справа доходить до таких вразливостей у програмному забезпеченні рівня 2 на біткойнах. По-перше, серйозність, з якою ці кодові бази перевіряються на наявність помилок у безпеці, і те, як це визначається пріоритетом порівняно з інтеграцією нових функцій. Я вважаю дуже показовим те, що безпека не завжди віддається пріоритету, враховуючи, що цю другу помилку навіть не знайшли розробники кодової бази, де вона була присутня, навіть якщо вона була буквально поруч із початковою помилкою, виявленою минулого місяця. Після однієї великої помилки, яка поставила під загрозу кошти користувачів, чи не проводився внутрішній аудит цієї кодової бази? Потрібен був хтось не учасник проекту, щоб це виявити? Це не свідчить про пріоритет збереження коштів користувачів над створенням нових функцій для залучення більшої кількості користувачів. По-друге, той факт, що цю проблему вже було виправлено в Rust Bitcoin, демонструє відсутність зв’язку між розробниками різних кодових баз щодо подібних помилок. Це цілком зрозуміло, оскільки наявність абсолютно різних кодових баз не змушує когось, хто знайшов помилку в одній, негайно подумати: «Мені слід зв’язатися з іншими командами, які пишуть подібне програмне забезпечення абсолютно різними мовами програмування, щоб попередити їх про потенціал такої помилки». Ви не знаходите помилку в Windows, а потім відразу думаєте повідомити про помилку розробникам ядра Linux. Однак біткойн як протокол для розподіленого консенсусу в глобальній мережі — зовсім інший звір; можливо, розробникам біткойн варто почати думати в цьому ключі, коли йдеться про вразливості програмного забезпечення біткойн. Особливо, коли мова йде про аналіз та інтерпретацію даних, пов’язаних із консенсусом.

Нарешті, можливо, коли йдеться про такі протоколи, як Lightning, які залежать від постійного спостереження за блокчейном, щоб мати можливість реагувати на старі стани каналу для підтримки безпеки, незалежний аналіз і перевірку даних слід звести до абсолютного мінімуму — якщо не видаляється повністю та делегується в Bitcoin Core або дані, безпосередньо отримані з нього. Core Lightning побудовано таким чином, що підключається до екземпляра Bitcoin Core і повністю залежить від нього для перевірки блоків і транзакцій. Якби LND працював так само, жодна з цих помилок у btcd не вплинула б на користувачів LND таким чином, щоб їхні кошти були під загрозою.

Незалежно від того, яким чином обробляти речі — або повністю передати валідацію аутсорсингу, або просто мінімізувати внутрішню перевірку та підходити до неї з більшою ретельністю — цей інцидент показує, що потрібно щось змінити в підході до питання того, як програмне забезпечення рівня 2 обробляє взаємодію з пов’язаними з консенсусом даними. Знову ж таки, усім дуже пощастило, що цим скористався не зловмисник, а натомість розробник, який підтвердив правоту. З огляду на це, біткойн не може розраховувати на те, що йому пощастить, або сподіватися, що зловмисників не існує.

Розробники та користувачі повинні зосередитися на вдосконаленні процесів, щоб запобігти повторенню подібних інцидентів, а не грати в гру, перекидаючи провину, як гарячу картоплю.

Це гостьовий пост від Shinobi. Висловлені думки повністю належать їм і не обов’язково збігаються з думками BTC Inc або Bitcoin Magazine.