Использование Lightning Bug было этическим выбором

Это редакционная статья Шиноби, преподавателя-самоучки в биткойн-пространстве и ориентированного на технологии ведущего биткойн-подкастов.

Во второй раз примерно за месяц в btcd/LND была обнаружена ошибка, из-за которой они отклонились от консенсуса с Bitcoin Core. И снова Бурак был разработчиком, который запустил эту уязвимость — на этот раз это было явно намеренно — и снова это была проблема с кодом для анализа транзакций Биткойн над уровнем консенсуса. Как я обсуждал в своем кусок предыдущей ошибки который запустил Бурак, до Taproot существовали ограничения на размер скрипта и данных-свидетелей в транзакции. С активацией Taproot эти ограничения были сняты, остались только ограничения на размер блока, ограничивающие эти части отдельных транзакций. Проблема с последней ошибкой заключалась в том, что, несмотря на то, что код консенсуса в btcd был должным образом обновлен с учетом этого изменения, код, обрабатывающий одноранговую передачу, включая анализ данных перед отправкой или при получении, не обновился должным образом. Таким образом, блоки обработки кода и транзакции до того, как он был фактически передан для проверки на предмет консенсуса, не смогли передать данные, никогда не передавали их в логику проверки консенсуса, и рассматриваемый блок никогда не был проверен.

На этот раз произошло очень похожее событие. Еще одним ограничением в одноранговой части кодовой базы было неправильное введение ограничения на данные-свидетели, ограничивавшие их максимум 1/8 размера блока, а не полным размером блока. Бурак создал сделка с данными-свидетелями всего на одну единицу веса сверх строгого предела, и узлы btcd и LND снова остановились на этой высоте блока. Эта транзакция была нестандартной транзакцией, а это означает, что, хотя она совершенно действительна по правилам консенсуса, она недействительна в соответствии с политикой мемпула по умолчанию, и поэтому узлы не будут ретранслировать ее по сети. Вполне возможно добыть его в блоке, но единственный способ сделать это — предоставить его непосредственно майнеру, что и сделал Бурак с помощью F2Pool.

Это действительно подтверждает тот факт, что любой фрагмент кода, целью которого является анализ и проверка данных Биткойна, должен подвергаться тщательному аудиту, чтобы убедиться, что он соответствует тому, что будет делать Bitcoin Core. Не имеет значения, является ли этот код механизмом консенсуса для реализации узла или просто частью кода, передающим транзакции для узла Lightning. Эта вторая ошибка была буквально прямо над тем, что было в прошлом месяце в кодовой базе. Его даже не обнаружил никто в Lightning Labs. Эй Джей Таунс сообщил об этом 11 октября, через два дня после того, как первоначальная ошибка была вызвана мультиподписной транзакцией Бурака 998 из 999. Он был публично опубликован на Github в течение 10 часов, прежде чем был удален. Затем было сделано, но не выпущено исправление с намерением незаметно исправить проблему в следующем выпуске LND.

Это довольно стандартная процедура для серьезной уязвимости, особенно для такого проекта, как Bitcoin Core, где такая уязвимость может фактически нанести серьезный ущерб сети/протоколу базового уровня. Но в данном конкретном случае это представляло серьезный риск для средств пользователей LND, а учитывая тот факт, что он находился буквально рядом с предыдущей ошибкой, которая имела такие же риски, шансы на то, что она будет найдена и использована, были очень высоки. как показал Бурак. Возникает вопрос, является ли подход «тихого исправления» подходящим подходом, когда речь идет о подобных уязвимостях, которые могут сделать пользователей уязвимыми для кражи средств (поскольку их узел не может обнаружить старые состояния канала и должным образом наказать их).

Как я уже говорил в своей статье о последней ошибке, если бы злоумышленник обнаружил ошибки раньше, чем разработчик с благими намерениями, он мог бы тактически открыть новые каналы для уязвимых узлов, направить все содержимое этих каналов обратно к себе, а затем воспользовался ошибкой. Оттуда они получат эти средства под свой контроль, а также смогут закрыть канал с исходным состоянием, буквально удвоив свои деньги. То, что сделал Бурак, активно иронически эксплуатируя эту проблему, фактически защитило пользователей LND от такой атаки.

После того, как это было использовано, пользователи были открыты для таких атак со стороны ранее существовавших пиров, с которыми у них уже были открытые каналы, но они больше не могли быть атакованы конкретно с помощью новых каналов. Их узлы были остановлены и никогда не распознавали и не обрабатывали платежи через каналы, которые кто-то пытался открыть после блока, который остановил их узел. Таким образом, хотя это и не устранило полностью риск эксплуатации пользователей, оно ограничило этот риск для людей, с которыми у них уже был канал. Действия Бурака смягчили ситуацию. Лично я считаю, что подобные действия в ответ на ошибку имели смысл; это ограничило ущерб, информировало пользователей о риске и привело к быстрому исправлению.

LND также оказалась не единственной пострадавшей стороной. жидкость процесс привязки также был нарушен, требуя обновлений от функционеров федерации, чтобы исправить это. Старые версии Rust Bitcoin также были затронуты, что привело к тому, что остановка повлияла на некоторые экземпляры обозревателей блоков и электрсов (реализация внутреннего сервера для Electrum Wallet). Теперь, за исключением привязки Liquid, которая в конечном итоге подвергает средства ключам аварийного восстановления, хранящимся у Blockstream после истечения срока блокировки - и, если реалистично в сюжете фильма в стиле ограбления, где Blockstream украл эти средства, все точно знают, за кем следует преследовать - эти другие проблемы никогда не подвергают риску чьи-либо средства. Кроме того, Rust Bitcoin фактически исправил эту конкретную ошибку в более новых версиях, что, по-видимому, не привело к какому-либо общению с сопровождающими других кодовых баз, чтобы подчеркнуть потенциал таких проблем. Только активное использование ошибки в сети широко выявило существование проблемы в нескольких базах кода.

Это порождает некоторые серьезные проблемы, когда речь идет об уязвимостях, подобных этой, в программном обеспечении уровня 2 Биткойна. Во-первых, серьезность, с которой эти кодовые базы проверяются на наличие ошибок безопасности, и то, насколько это приоритетно по сравнению с интеграцией новых функций. Я думаю, очень показательно, что безопасность не всегда является приоритетом, учитывая, что эта вторая ошибка даже не была обнаружена сопровождающими кодовой базы, в которой она присутствовала, хотя она была буквально рядом с первоначальной ошибкой, обнаруженной в прошлом месяце. Разве не был проведен внутренний аудит этой кодовой базы после одной серьезной ошибки, которая поставила под угрозу средства пользователей? Чтобы это обнаружить, понадобился кто-то извне проекта? Это не демонстрирует приоритета защиты средств пользователей над созданием новых функций для привлечения большего количества пользователей. Во-вторых, тот факт, что эта проблема уже исправлена ​​в Rust Bitcoin, демонстрирует отсутствие взаимодействия между сопровождающими различных кодовых баз в отношении подобных ошибок. Это вполне понятно, поскольку совершенно разные кодовые базы не заставляют человека, обнаружившего ошибку в одной, сразу подумать: «Мне следует связаться с другими командами, пишущими аналогичное программное обеспечение на совершенно разных языках программирования, и предупредить их о возможности возникновения такой ошибки». Вы не находите ошибку в Windows, а затем сразу же думаете сообщить об ошибке специалистам по поддержке ядра Linux. Однако Биткойн как протокол для распределенного консенсуса в глобальной сети — совсем другое дело; возможно, разработчикам биткойнов следует начать думать в том же духе, когда речь идет об уязвимостях в программном обеспечении биткойнов. Особенно, когда дело доходит до анализа и интерпретации данных, связанных с консенсусом.

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

Какой бы способ ни был решен — либо полностью передать проверку на аутсорсинг, либо просто свести к минимуму внутреннюю проверку и подойти к ней с гораздо большей осторожностью — этот инцидент показывает, что что-то необходимо изменить в подходе к вопросу о том, как программное обеспечение уровня 2 обрабатывает взаимодействие с данными, связанными с консенсусом. Еще раз, всем очень повезло, что этим воспользовался не злоумышленник, а разработчик, доказавший свою точку зрения. При этом Биткойн не может рассчитывать на удачу или надеяться на то, что злоумышленников не существует.

Разработчики и пользователи должны сосредоточиться на совершенствовании процессов, чтобы предотвратить повторение подобных инцидентов, а не играть в игру, в которой обвиняют, как горячую картошку.

Это гостевой пост Шиноби. Высказанные мнения являются полностью их собственными и не обязательно отражают точку зрения BTC Inc или Bitcoin Magazine.