Bitcoin Core ввёл ускоренное раскрытие легко находимых уязвимостей

Bitcoin Core изменил порядок раскрытия исправлений безопасности для ошибок, которые легко найти заново — в том числе простым запросом к языковой модели. Правка объединена 22 октября. В тот же день о ней написал в рассылке Bitcoin Development участник проекта из Chaincode Labs Антуан Пуансот.

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

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

Почему прежний график перестал подходить

До сих пор сроки зависели от степени серьёзности. Ошибки низкого уровня раскрывались через две недели после выхода следующего основного релиза. Средние и высокие оставались закрытыми до двух недель после окончания поддержки последнего затронутого выпуска — на практике около года с момента первого основного релиза с исправлением.

Долгое эмбарго было связано с культурой обновлений: Bitcoin Core — эталонная реализация, на которой работает большинство нод сети, а операторы обновляют софт медленно и осознанно. Исправления безопасности при этом обычно не переносились в старые ветки, и пользователь более ранней версии ждал следующего основного релиза — примерно раз в полгода. Те же причины объясняют консерватизм изменений уровня консенсуса, включая апгрейд Taproot.

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

ИИ меняет расстановку рисков. Если проблему находят повторно автоматическим поиском или запросом к чат-боту, сокрытие почти ничего не даёт сети, а задержка с выпуском исправления мешает закрыть риск.

Что даёт новая категория

В политике появился третий сценарий: при классификации уязвимость может получить статус «Легко обнаруживаемая». Критерий — не инструмент, которым её нашли, а дешевизна повторного обнаружения: проблема, изначально найденная человеком, тоже может попасть в эту категорию.

Для таких случаев патч будут переносить во все поддерживаемые основные версии — по правилам проекта это последние три релиза. Затем выпускаются точечные обновления, а уведомление о безопасности публикуется одновременно с исправленным софтом.

Остальная шкала сохранилась. Низкая серьёзность — раскрытие через две недели. Средняя и высокая — примерно годовой цикл, если ошибку не признали легко обнаруживаемой. Критические уязвимости, способные привести к краже монет на уровне протокола, росту эмиссии или необратимому расколу цепи, по-прежнему рассматриваются вне стандартной процедуры. К такому уровню относился инфляционный баг CVE-2018-17144, найденный в сентябре 2018 года: он позволял создавать монеты вне графика эмиссии. Ускоренный режим для подобных случаев не предназначен.

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

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

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

Чем платят за скорость

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

«Это особенно важно, поскольку при такой политике исправления будут иметь меньше времени на выдержку в ветках разработки перед выпуском пользователям», — написал Пуансот в запросе на слияние.

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

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

Первый реальный тест ещё впереди

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

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

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