Bitcoin Core отменяет годичное эмбарго для уязвимостей, которые может выявить один запрос к ИИ

Почему годичное эмбарго перестало приносить пользу

Прежняя политика Bitcoin Core связывала сроки раскрытия информации с уровнем серьезности уязвимости. Информацию об уязвимостях низкого уровня раскрывали через две недели после выхода следующего крупного релиза. Уязвимости среднего и высокого уровня оставались непубличными до истечения двух недель после завершения срока поддержки последнего затронутого релиза. В самой политике этот срок описан как «примерно год после первого выпуска крупной версии, содержащей исправление».

У такого графика были причины. Bitcoin Core является эталонной реализацией, на которой работает большинство узлов Bitcoin, а операторы узлов обновляются медленно. Длительное эмбарго должно было дать сети время на установку исправлений до публичного раскрытия деталей. Компромисс заключался в том, что исправления, как правило, не переносились в более ранние версии, поэтому оператору старого релиза приходилось ждать следующей крупной версии, которую проект стремится выпускать примерно каждые шесть месяцев.

Осторожный подход обусловлен особенностями самой системы, а не случайностью. Изменения консенсуса, такие как обновление Taproot в Bitcoin, проходят медленный и консервативный процесс именно для того, чтобы операторы могли внедрять их по собственному графику.

«Учитывая специфику нашего проекта и медленную культуру обновлений, наша политика безопасности предусматривает более длительный период эмбарго», написал Пуансо. «Обычно это означает, что исправления безопасности нельзя переносить в более ранние версии, и они становятся доступны пользователям только вместе со следующим крупным релизом».

ИИ нарушает этот компромисс. Если уязвимость можно обнаружить заново с помощью простого сканирования большой языковой моделью, скрывать ее бессмысленно, поскольку она уже доступна любому, у кого есть чат-бот. «Для таких уязвимостей, которые легко обнаружить, этот компромисс неверен. Период эмбарго почти ничего не дает, зато задерживает выпуск версии с исправлением», написал Пуансо.

Что именно меняет новая категория «легко обнаруживаемых» уязвимостей

В пересмотренной политике теперь есть третий вариант срока раскрытия информации. При первичной оценке уязвимость можно пометить как «легко обнаруживаемую». Так называют уязвимость, которую «можно обнаружить с минимальными усилиями, например с помощью простого запроса к большой языковой модели». Эта категория не ограничивается уязвимостями, найденными с помощью ИИ: критерий здесь в том, насколько легко обнаружить уязвимость заново, а не в том, какой инструмент использовали для ее обнаружения.

Для таких уязвимостей меняется весь порядок действий. Вместо одного исправления в следующем крупном релизе сопровождающие разработчики перенесут исправление во все крупные версии, поддерживаемые на данный момент. Согласно правилу Bitcoin Core, поддерживаются три последние версии, а исправления будут выпущены в виде промежуточных релизов так быстро, как только возможно. Предупреждение о безопасности будет опубликовано одновременно с исправленным программным обеспечением.

Для всех остальных уязвимостей по-прежнему действует градация по уровню серьезности. Уязвимости низкого уровня раскрываются по графику в две недели. Для уязвимостей среднего и высокого уровня сохраняется срок примерно в год. Критические уязвимости, которые могут привести к краже монет на уровне протокола, увеличению предложения или необратимому разделению блокчейна, по-прежнему не подпадают под стандартную политику: как и прежде, каждую из них рассматривают отдельно.

Исключение сделано не без причины. В истории Bitcoin Core к уязвимостям, требующим особого подхода, относилась ошибка инфляции, о которой сообщили в сентябре 2018 года под номером CVE-2018-17144: она могла позволить создавать монеты вне графика эмиссии. Новый порядок для «легко обнаруживаемых» уязвимостей эту категорию не затрагивает. Реакцию на критическую уязвимость и впредь будут подбирать в индивидуальном порядке с учетом риска для всей сети.

Две недели, год или «как можно скорее»

Изменение проще всего понять как сокращение периода раскрытия информации. Уязвимость среднего уровня, исправленная сегодня, обычно оставалась бы непубличной около 52 недель, а информация о ней раскрывалась бы лишь через две недели после завершения срока поддержки последнего затронутого релиза. Если же ту же уязвимость пометить как легко обнаруживаемую, исправление выпустят в виде промежуточного релиза «как можно скорее», одновременно с предупреждением о безопасности. По формулировке самих сопровождающих разработчиков, вместо года останется только срок, необходимый для написания, проверки и тестирования целевого исправления.

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

Риск, на который указали сами сопровождающие разработчики

У ускоренного порядка есть цена, и Пуансо прямо указал на нее в запросе на включение изменений. «Это особенно важно, потому что при такой политике меры по устранению уязвимостей будут меньше времени “отстаиваться” в ветках разработки до выпуска для пользователей», написал он. Исправление, выпущенное за несколько дней, меньше времени проходит проверку и тестирование, чем исправление, которое оставалось там месяцами.

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

Это обсуждение важно, потому что показывает: новая политика представляет собой сознательно выбранный компромисс, а не очевидное решение. В утвержденном тексте сохранено одновременное с исправлением предупреждение о безопасности, а также полное раскрытие деталей вместо расплывчатого предупреждения.

Когда появляется первая «легко обнаружимая» ошибка

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

Более широкий сигнал заключается в том, что поиск ошибок с помощью ИИ уже заставил экосистему Bitcoin измениться. Ранее в этом году Core Lightning призвал операторов узлов обновить ПО или отключиться после того, как отчёты об уязвимостях, сгенерированные ИИ, оказались верными. Изменение политики Bitcoin Core показывает, что эталонная реализация пришла к тому же выводу на базовом уровне протокола: когда повторное обнаружение обходится дёшево, секретность мало что даёт, а длительная отсрочка раскрытия лишь задерживает выпуск исправления.

Для операторов узлов сегодня ничего не меняется. Периодичность обновлений остаётся прежней. Разница проявится в следующий раз, когда ошибка будет признана легко обнаружимой: исправление и уведомление о нём выйдут одновременно, и сеть получит меньше времени на подготовку, чем когда-либо прежде.