Разработчики Core Lightning попросили операторов узлов принять решение по безопасности до того, как они смогут полностью оценить угрозу. В сообщении от 23 августа, опубликованном на Stacker News, операторам было предложено установить новые бинарные файлы, исправляющие несколько зарегистрированных уязвимостей.
CLN заявил операторам, отказывающимся от обновления, запускать свои узлы в офлайн-режиме, и команда планирует сохранять технические детали под эмбарго в течение двух недель.
CLN планирует прикрепить к бинарным файлам подписи команды, чтобы пользователи могли проверить происхождение и воспроизводимость. Документированный процесс релиза Core Lightning использует подписанные теги, подписанные контрольные суммы и воспроизводимые сборки.
Эти средства контроля позволяют операторам убедиться, что пакет прошел через предусмотренный процесс релиза.
Операторы пока не могут изучить доказательства, лежащие в основе оценки угрозы CLN, или определить механизм эксплуатации из публичных материалов. У них также недостаточно информации, чтобы оценить, сталкивается ли конкретная конфигурация узла с таким же риском.
Биткоин предоставляет пользователям инструменты для проверки монетарных правил без необходимости запрашивать разрешение у банка или платежного процессора.
Инцидент с безопасностью живого программного обеспечения действует в иных условиях, поскольку предоставление каждому пользователю достаточных доказательств для проверки эксплойта может дать атакующему ту же информацию.
| Уровень | Что операторы могут проверить сейчас | Что остается неизвестным во время эмбарго |
|---|---|---|
| Происхождение ПО | Бинарные файлы прошли через предусмотренный процесс релиза CLN | Влияют ли исправленные проблемы на каждую конфигурацию узла |
| Подлинность релиза | Подписанные теги и подписанные контрольные суммы | Точные механизмы уязвимостей |
| Целостность сборки | Воспроизводимые сборки могут связать исходный код и бинарный файл | Подвергают ли старые бинарные файлы определенному пути атаки |
| Одобрение мейнтейнеров | Подписи команды подтверждают владение релизом | Серьезность каждой зарегистрированной проблемы |
| Оперативное реагирование | CLN рекомендует обновление или переход в офлайн | Необходим ли режим --offline для каждого оператора |
Эмбарго создает временную информационную иерархию
Последовательность событий началась около 13 августа, когда CLN сообщил, что получил несколько сгенерированных ИИ отчетов CVE из нескольких источников примерно за 10 дней. Команда CLN начала проверку отчетов, к работе подключились внешние участники open-source, и разработчики также начали готовить исправления.
К 23 августа команда CLN подготовила бинарные файлы, содержащие исправления для многих из зарегистрированных уязвимостей.
Они также заявили, что прекратят поддержку предыдущих релизов, включая 26.04, «учитывая известные риски».
Blockstream выпустил две версии CLN во втором квартале: 26.04 в апреле и 26.06 в июне. Его обновление за второй квартал поместило версию 26.09 в дорожную карту третьего квартала.
Доступные материалы не содержат доказательств эксплуатации в реальных условиях и не дают оснований рассматривать каждый отчет как одинаково серьезный.
Таким образом, оператор сталкивается с двумя уровнями проверки, и первый охватывает сам артефакт. Процесс релиза CLN предоставляет пользователям инструменты для аутентификации тегов релиза, контрольных сумм и воспроизводимых сборок.
Второй уровень охватывает угрозу, поскольку операторам все еще не хватает технических деталей, необходимых для оценки того, на что способны ошибки, или соответствует ли переход в офлайн их собственной подверженности риску.
Скоординированное раскрытие информации о безопасности может задержать эти доказательства, поскольку публикация также меняет информационный набор атакующего.
Core Lightning откладывает полную прозрачность для защиты развертывания патчей
Руководство CERT по скоординированному раскрытию уязвимостей гласит, что процесс направлен на минимизацию преимущества противника во время исправления. Его руководство по развертыванию также проводит различие между доступностью патча и его развертыванием.
| Вариант раскрытия | Преимущество | Риск |
|---|---|---|
| Немедленное полное техническое раскрытие | Операторы могут самостоятельно оценить угрозу | Атакующие могут узнать путь эксплойта до установки патча узлами |
| Эмбарго с подписанными бинарными файлами | Дает операторам время для безопасного обновления | Пользователи должны временно доверять суждению мейнтейнеров |
| Патч доступен, но не широко развернут | Исправление существует для подготовленных операторов | Незапатченные узлы остаются уязвимыми |
| Отложенные публичные детали | Снижает преимущество атакующего во время развертывания | Может вызвать подозрения или нерешительность |
| Раскрытие после эмбарго | Восстанавливает независимую проверку | Доверие истекает только в случае четкой публикации доказательств |
Подробное раскрытие могло бы помочь опытным атакующим определить уязвимый путь в старом ПО, и незапатченные операторы тогда столкнулись бы с угрозой, вооруженной теми же техническими доказательствами, которые они хотели для независимой проверки.
Подписанные бинарные файлы сужают требование доверия: операторы могут аутентифицировать, кто выпустил релиз, а воспроизводимые сборки могут подтвердить связь между исходным кодом и бинарным файлом.
Программное обеспечение Биткоина уже зависит от человеческого суждения на этом уровне, поскольку мейнтейнеры решают, требует ли зарегистрированная ошибка экстренного лечения. Инженеры релиза решают, когда исправление можно безопасно выпустить, а команды безопасности решают, сколько информации пользователи могут получить до того, как раскрытие создаст дополнительный риск.
Одновременное раскрытие стерло бы временное информационное преимущество, которое защитники пытаются сохранить.
Оптимистичный сценарий исходит из того, что этот процесс работает чисто: операторы аутентифицируют релиз и переходят на исправленное ПО. Затем Core Lightning публикует технические детали, подтверждающие срочность его предупреждения.
Такая последовательность укрепила бы доверие к мейнтейнерам и процессу релиза, поскольку временное доверие истекло бы, превратившись в независимо проверяемые доказательства.
Пессимистичный сценарий начинается с нерешительности. Некоторые операторы узлов могут сопротивляться обновлению, модель угроз которого они не могут проверить, а другие могут выбрать режим –offline.
Core Lightning документирует этот режим как предотвращающий привязку узла к портам или повторное подключение к пирам. Достаточное количество отложенных обновлений или офлайн-узлов может снизить доступность маршрутизации в частях сети.
Затяжной разрыв между предупреждением и доказательствами также может превратить технический процесс раскрытия в проблему доверия к мейнтейнерам.
ИИ сжимает окно для «проверить позже»
ИИ добавляет еще одно ограничение к модели раскрытия. Google пересмотрел свою программу вознаграждений за уязвимости в open-source ПО в марте, поскольку увидел «огромный всплеск» отчетов, сгенерированных ИИ.
Google заявил, что многие заявки содержали неверную информацию или вымышленные пути эксплойтов. Компания начала требовать более веских доказательств для некоторых уровней отчетов, чтобы команды триажа могли сосредоточиться на реальных угрозах.
| Фаза раскрытия | Традиционное давление | Давление в эпоху ИИ |
|---|---|---|
| Прием отчетов | Исследователи-люди предоставляют находки в ограниченном масштабе | Отчеты, сгенерированные ИИ, могут поступать большими партиями |
| Триаж | Мейнтейнеры отделяют валидные ошибки от шума | Команды должны быстрее фильтровать вымышленные или слабые отчеты |
| Валидация | Разработчики воспроизводят и ранжируют заслуживающие доверия проблемы | Автоматизация может увеличить объем до того, как люди подтвердят серьезность |
| Разработка патча | Исправления создаются до появления публичных деталей | Больше сторон могут повторно обнаружить аналогичные ошибки во время эмбарго |
| Развертывание у пользователей | Операторы устанавливают патч до полного раскрытия | Атакующие могут использовать diff-файлы, бинарные файлы или подсказки для более быстрого поиска |
| Финальное раскрытие | Доказательства становятся независимо проверяемыми | Окно для «проверить позже» может сократиться |
Сообщения CLN описывают связанную нагрузку: несколько сгенерированных ИИ отчетов поступили из нескольких источников примерно за 10 дней. Людям все еще приходилось проверять находки, прежде чем разработчики могли рассматривать их как уязвимости.
Google уже продемонстрировал, что фаззинг, сгенерированный ИИ, может выявлять уязвимости в зрелых open-source проектах, включая OpenSSL. Инструменты, снижающие стоимость обнаружения уязвимостей, также могут облегчить повторное обнаружение, как только исследователи получат запатченный бинарный файл, разницу в коде или другую техническую подсказку.
Мейнтейнерам нужно окно для проверки ошибки и еще одно окно для распространения исправления до того, как знания об эксплойте распространятся. ИИ может поглотить первое окно объемом отчетов и сжать второе за счет более дешевого автоматизированного поиска.
Криптография может минимизировать доверие, необходимое для проверки транзакций, балансов и программных артефактов. Операционная безопасность может потребовать временного доверия к суждению мейнтейнеров, когда немедленное раскрытие также улучшило бы позицию атакующего.
Последующее раскрытие Core Lightning может закрыть этот разрыв. До тех пор операторы, выполняющие обновление, принимают ограниченную форму доверия внутри программного обеспечения, построенного вокруг независимой проверки. Модель успешна, когда у этого доверия есть срок годности и приходят доказательства.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Gino Matos
