news

Эксплуатация ошибки Lightning была этичным выбором


14.11.2022

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

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

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

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

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

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

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

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

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

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

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

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

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

Зарабатывай BTC на кране Freebitco.in — каждый час до $200.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *