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

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

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

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

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

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

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

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

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

Пострадало не только LND. Процесс привязки Liquid также был нарушен, и для его исправления потребовались обновления для функционеров федерации. Старые версии 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 обрабатывает взаимодействие с данными, связанными с консенсусом. . И снова всем очень повезло, что этим воспользовался не злоумышленник, а разработчик, доказывающий свою точку зрения. При этом Биткойн не может рассчитывать на удачу или надежду на то, что злоумышленников не существует.

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

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