Баг в Docker-образе Bitcoin Core Lightning оставляет ноды уязвимыми, несмотря на отображение обновленной версии

Разработчики программного обеспечения Bitcoin Lightning сообщают, что четыре тега образов поставили неисправленные бинарные файлы при запуске версии v26.06.7, оставив затронутым пользователям еще одну задачу: проверить хеш образа и загрузить исправленный образ, если он отличается.

Некоторые операторы Core Lightning, пытавшиеся обновить версию до v26.06.7 через Docker, могут по-прежнему не иметь установленных исправлений безопасности.

В обновленном уведомлении о выпуске указаны затронутые теги: v26.06.7, latest, v26.06.7-vls и latest-vls. Они поставляли образы без исправлений этого выпуска с 28 августа, 16:04 UTC, по 1 сентября. В уведомлении не указано точное время окончания этого периода.

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

Выпуск от 28 августа установил 14-дневный эмбарго на публикацию исходного кода, указывая на запланированное раскрытие информации 11 сентября. По состоянию на 8 сентября в уведомлении все еще описывается предстоящая публикация. Разработчики говорят, что задержка дает операторам время для обновления до того, как потенциальные злоумышленники смогут провести обратную разработку исправлений.

Как проверить образ Docker для исправления ошибки Lightning

Разработчики просят всех, кто ранее загружал один из четырех тегов, сравнить его хеш (идентификатор образа) с исправленными значениями:

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

docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7

Если хеш отличается, соответствующая команда для загрузки:

docker pull elementsproject/lightningd:v26.06.7

В уведомлении также приводится команда docker pull elementsproject/lightningd:latest для этого тега. Пользователям VLS требуется отдельный хеш VLS из таблицы. Их настройка VLS_CLN_VERSION также должна соответствовать v26.06.7, иначе remote_hsmd_socket откажется запускаться; сам подписывающий модуль остается VLS v0.14.0.

Пользователи, зафиксированные на версии v26.06.6 или более ранней, избежали этой ошибки упаковки. Исключение касается ошибочной упаковки; новые исправления безопасности относятся к версии v26.06.7.

Исправление упаковки меняет непосредственную проблему оператора: попытка обновления может потребовать повторной проверки, пока это окно остается открытым.

Существует еще одна ловушка при загрузке во время эмбарго. Автоматически прилагаемые архивы исходного кода GitHub не являются исходным кодом v26.06.7, предупреждают разработчики, поэтому сборка этих архивов не приведет к созданию заявленных исправленных бинарных файлов.

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