Недавно обнаруженная критическая уязвимость в фреймворке для обработки мультимедиа FFmpeg, который используется в огромном количестве приложений с открытым исходным кодом и коммерческих приложениях, вновь указывает на необходимость выработки у руководителей служб безопасности (CSO) стратегий по борьбе с уязвимостями в цепочке поставок программного обеспечения, которые должны включать требование предоставления спецификации материалов программного обеспечения (SBOM) для всех продуктов.
Уязвимость (CVE-2026-8461), обнаруженная исследователями JFrog, представляет собой запись за пределами границ кучи (heap out-of-bounds write) в декодере MagicYUV, которая может привести к сбою любого приложения, использующего этот фреймворк. Он задействован во всем: от настольных видеоплееров, таких как Kodi и mpv, до генераторов миниатюр файловых менеджеров Linux и облачных конвейеров транскодирования (например, AWS MediaConvert и Cloudflare Stream), а также медиасерверов, размещенных на собственных серверах.
Эта уязвимость получила название PixelSmash.
«Уязвимость может быть использована для вывода систем из строя, а в худших случаях может привести к удаленному выполнению кода, что означает, что команды по безопасности и разработчики должны отнестись к ней серьезно и приоритизировать ее устранение», — заявил в электронном письме Юваль Моравчик, руководитель группы по исследованию уязвимостей в JFrog. «CSO и разработчики должны убедиться, что их продукты безопасности приложений уведомляют их о наличии этой уязвимости, чем раньше, тем лучше».
Исследователи сообщили, что продемонстрировали полную эксплуатацию, добившись удаленного выполнения кода на двух независимых целях: медиасервере Jellyfin (через автоматическое сканирование библиотеки) и экземпляре платформы для совместной работы Nextcloud (через поставщика предварительного просмотра видео), в обоих случаях просто загрузив специально созданный AVI-файл размером 50 КБ.
Фактически, любой специально созданный медиафайл (контейнер AVI, MKV или MOV) сработает в приложении, использующем libavcodec от FFmpeg. Уязвимым может оказаться даже папка с файлами, содержащая приложение, поскольку ошибку вызовет генератор миниатюр файлового менеджера.
«Достаточно обработать один вредоносный медиафайл», — утверждают исследователи.
Существует одно временное решение: если декодер MagicYUV не нужен, разработчики могут отключить его на этапе сборки.
Однако Гарретт Калпузос, ведущий исследователь безопасности в Sonatype, сомневается, что полная эксплуатация станет распространенным явлением. «Я был бы удивлен, увидев широкое и надежное использование этой конкретной ошибки в современных, защищенных средах», — сообщил он CSO по электронной почте. «Более реалистичный краткосрочный риск — это отказ в обслуживании (DoS), особенно для сервисов, обрабатывающих недоверенные мультимедиа в больших масштабах».
Тем не менее, пользователям FFmpeg следует как можно скорее обновиться до пропатченной версии (8.1.2), если они знают, что она используется в их приложении, или если об этом их уведомили поставщики.
Фундаментальная зависимость
JFrog отмечает, что FFmpeg поставляется или используется практически в каждом приложении для обработки мультимедиа на любой платформе. Компания подтвердила сбои в работе Kodi, mpv, ffmpegthumbnailer (используется GNOME, KDE, XFCE), Jellyfin, Emby, Nextcloud, Immich, PhotoPrism и OBS Studio, среди прочих.
Уязвимость представляет собой единую ошибку в декодере кодека внутри FFmpeg, но это фундаментальная зависимость, внедренная в сотни нижестоящих проектов, которая каскадно затрагивает каждое приложение, использующее libavcodec — библиотеку с открытым исходным кодом, предоставляющую основные возможности кодирования и декодирования аудио- и видеопотоков.
Исследователи отмечают, что ни один из затронутых проектов не вносил эту ошибку. Они унаследовали ее незаметно через свою зависимость от FFmpeg. И, по их словам, у большинства нет механизма для ее самостоятельного обнаружения или смягчения последствий.
Это не первая проблема безопасности в FFmpeg. Как ранее в этом месяце указали исследователи DepthFirst, команда Google Big Sleep раскрыла 13 уязвимостей, а Anthropic, используя свою модель Claude Mythos preview, обнаружила 16-летнюю брешь. В апреле исследователи SentinelOne описали уязвимость переполнения буфера, а в декабре прошлого года исследователи ZeroPath сообщили об обнаружении семи уязвимостей памяти.
Борьба с уязвимостями цепочки поставок
Уязвимости в цепочке поставок программного обеспечения, вызванные слабостями в сторонних библиотеках и компонентах с открытым исходным кодом, давно известны как угроза безопасности. Пожалуй, самой печально известной является компрометация в 2020 году механизма обновления платформы управления ИТ-инфраструктурой SolarWinds Orion, в ходе которой российская хакерская группировка APT20/Cozy Bear внедрила бэкдор в легитимное обновление, отправленное 18 000 клиентам, хотя эксплуатирована была гораздо меньшая группа.
Для борьбы с уязвимостями цепочки поставок эксперты считают, что разработчики должны внедрять стратегии для тщательной проверки кода перед его развертыванием. К ним относятся анализ состава программного обеспечения (software composition analysis), который дает представление о зависимостях ПО, статическое тестирование безопасности приложений (static application security testing), сканирование контейнеров и наличие или генерация спецификации материалов программного обеспечения (SBOM).
[Связанный материал: Что такое SBOM?]
Критическая роль SBOM
SBOM легко создать, если разработчик создает собственное приложение. Их сложнее получить от загруженных или коммерческих приложений.
Йоханнес Ульрих, декан отдела исследований в SANS Institute, сообщил CSO, что прозрачное декларирование зависимостей через SBOM имеет решающее значение для того, чтобы организации могли точно понимать риски, исходящие от программного обеспечения. В частности, поставщики коммерческого ПО часто неохотно раскрывают компоненты; воспринимаемая ценность, которую пытается продемонстрировать коммерческое ПО, часто несовместима с обертками, которые оно реализует вокруг общеиспользуемых компонентов с открытым исходным кодом.
Одной из проблем с уязвимостью PixelSmash, отметил он, является то, что использование FFmpeg в приложении часто не является ни очевидным, ни задекларированным. SBOM помог бы CSO или руководителям команд разработки быстро узнать, затронуты ли какие-либо из их приложений.
Что потребуется, чтобы побудить CSO сделать SBOM частью своих стратегий безопасности? «Нормативное соответствие», — ответил Ульрих. «Эти изменения обычно вносятся только тогда, когда того требует соответствие нормам. Определенное влияние могут оказать государственные заказчики, требующие SBOM, но и это произойдет только в том случае, если это будет предусмотрено руководящими принципами закупок».
Урок: Управление поверхностью атаки
Калпузос из Sonatype отметил, что одним из важных уроков, извлеченных из обнаружения PixelSmash для предприятий, является управление поверхностью атаки. MagicYUV — это нишевый формат видео без потерь, используемый больше в высококлассных рабочих процессах видеомонтажа, чем в основной доставке видео в Интернете, и FFmpeg обычно собирается со всеми включенными декодерами, что означает, что большинство приложений в конечном итоге раскрывают пути кода, которые им, возможно, никогда не понадобятся. Командам по информационной безопасности необходимо убедиться, что они включают только те форматы и функции, которые их организация фактически использует в приложениях.
«Именно здесь важны SBOM», — добавил он. «Большинство организаций не имеют полного представления о том, где внедрен FFmpeg, скомпилирован ли он вместе с приложением или статически связан, или какие необязательные функции включены. SBOM помогает командам безопасности перейти от вопроса «Защищены ли мы?» к вопросу «Где мы уязвимы и как быстро мы можем это исправить?». В эпоху ИИ злоумышленники и исследователи могут все чаще прочесывать зрелые проекты с открытым исходным кодом в поисках упущенных уязвимостей в малоизвестных функциях, поэтому организации должны знать, что они поставляют, минимизировать то, что они выставляют наружу, сохранять включенными настройки безопасности по умолчанию и быстро устанавливать исправления».
Рекомендации по SBOM
Агентство по кибербезопасности и защите инфраструктуры США (CISA) распространило предлагаемый перечень минимальных элементов, которые должна включать спецификация материалов программного обеспечения.
«Эффективный механизм для обмена и использования данных о программном обеспечении должен быть машиночитаемым и масштабируемым», — отмечается в документе. «Модель SBOM достигает этого, фиксируя данные о компонентах программного обеспечения в машиночитаемом формате и поддерживая операции по их анализу, обмену и управлению. Данные SBOM могут быть сопоставлены с другими источниками данных, такими как консультации по безопасности или базы данных «одобренного/неодобренного» ПО на уровне организации, для улучшения других приоритетных практик (например, безопасная разработка ПО, управление уязвимостями). SBOM не решит все проблемы безопасности ПО и цепочки поставок, но это необходимый шаг, который обеспечивает и расширяет возможности принятия решений по безопасности, основанных на оценке рисков».
Отдельно в прошлом месяце рабочая группа G7 по кибербезопасности, в которую входят США, Германия, Канада, Франция, Италия, Япония, Великобритания и Европейский Союз, выпустила совместное руководство Software Bill of Materials for AI – Minimum Elements, чтобы помочь заинтересованным сторонам из государственного и частного секторов повысить прозрачность своих систем искусственного интеллекта (ИИ) и цепочек поставок.
Однако Моравчик из JFrog утверждает, что, хотя спецификация материалов программного обеспечения является важным первым шагом, это лишь отправная точка для создания более безопасных приложений. «Команды, которые остаются впереди, сочетают это с непрерывным сопоставлением CVE и анализом возможности эксплуатации, сканированием на уровне двоичных файлов, где фактически находятся эти зависимости, и отключением кодеков и функций, которые они не используют», — сказал он CSO.
Руководителям служб информационной безопасности также необходимо перейти от реагирования к проактивному контролю, сказал он. Это означает перемещение принудительного обеспечения безопасности вверх по течению, чтобы риск блокировался у входа, посредством автоматизированного управления каждым пакетом, моделью и агентным инструментом, поступающим в конвейер, в сочетании с обнаружением угроз на базе ИИ, а не устранением последствий в реальном мире после публикации CVE.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Howard Solomon
