Библиотека libextractor из проекта GNU извлекает метаданные из файлов десятков форматов: заголовки, имена авторов, названия вложений, содержимое архивов. В её плагине для формата OLE2 нашлась уязвимость, из-за которой слишком длинный блок данных из документа переполняет буфер на стеке. Злоумышленник отправляет подготовленный файл .doc, и приложение, разбирающее его через эту библиотеку, падает. В многопоточных сборках у атакующего появляется возможность выполнить собственный код. Уязвимость зарегистрирована под идентификатором CVE-2026-91752. Нашёл её исследователь Haitam Lazaar, координатором выступила компания VulnCheck. Оценка по CVSS 4.0 - 8.7 балла, по CVSS 3.1 - 7.5. Библиотека распространяется свободно и входит в состав многих дистрибутивов Linux, поэтому её версия в системе не всегда очевидна.
Уязвимость CVE-2026-91752
Формат OLE2 знаком по старым документам Word, таблицам Excel и презентациям PowerPoint. По сути это контейнер, внутри которого лежат вложенные потоки с текстом, изображениями и служебными сведениями. Плагин libextractor читает такой поток и берёт его размер прямо из файла: автор документа задаёт это значение сам. Затем размер попадает в объявление массива на стеке, то есть в массив переменной длины. Стек - небольшой ресурс с жёстким пределом, обычно от одного до восьми мегабайт на поток. Потолок в четыре мегабайта, который поставили разработчики, почти ничего не меняет: в него укладывается значительная часть стека. Данные пишутся в буфер, и стек переполняется. Классификация относит проблему к двум категориям: выделение памяти по чрезмерно большому значению (CWE-789) и переполнение буфера на стеке (CWE-121).
Первое последствие - отказ в обслуживании. Для атаки не нужны учётные данные, не требуется и участие пользователя: достаточно, чтобы сервис принял файл на обработку. Документы приходят через загрузку на портал, письмо с вложением или общую сетевую папку, поэтому сетевой вектор здесь не теоретический. Падение разбора обрывает всю операцию. Если разбор идёт в рабочем процессе сервиса, вместе с парсером уходит и сам сервис. Свойства уязвимости удобны для злоумышленника: низкая сложность эксплуатации, отсутствие требований к привилегиям, автоматическое срабатывание при разборе файла.
Второе последствие тяжелее. Современные компиляторы добавляют проверку, которая ловит резкий прыжок указателя стека, - защиту от конфликтов стека, известную как -fstack-clash-protection. В однопоточном приложении она превращает атаку в обычное падение, и выполнить код не удаётся. В многопоточной программе стеки потоков расположены в памяти рядом. Проверки проходят по чужому стеку, защита не срабатывает, и переполнение становится управляемым. Разработчики признают такой обход рабочим и описывают методику в сопроводительных материалах к находке.
Страдают все версии библиотеки с плагином OLE2 вплоть до 1.14. Круг пострадавших не ограничен утилитой командной строки. libextractor подключают почтовые шлюзы, индексаторы файлов, поисковые системы, сервисы загрузки документов, сканеры вложений. В самом проекте GNU на неё опирается GNUnet - инструмент для обмена и индексирования файлов в распределённой сети. Проверки показали, что публикация подготовленного документа в GNUnet роняет служебный процесс, отвечающий за работу с файлами. Встраивают библиотеку и в серверные приложения, которые принимают вложения от внешних пользователей.
Демонстрационный стенд исследователь собрал на контейнерах. Скрипт создаёт вредоносный документ и отправляет его веб-сервису, индексирующему загруженные файлы. Сервис падает, а в сценарии с обходом защиты на сервере выполняется произвольная команда. Стенд воспроизводим, конфигурация открыта, поэтому выводы может проверить каждый. Для служб безопасности это удобная возможность протестировать собственные фильтры и убедиться, что вредоносный документ не доходит до парсера.
Исправление появилось в libextractor 1.15. Разработчики отказались от массива переменной длины. Теперь плагин работает с буфером фиксированного размера и читает из потока ровно столько байт, сколько тот вмещает. Обновление снимает и сценарий с отказом в обслуживании, и сценарий с выполнением кода. Администраторам нужно обновить библиотеку вместе с приложениями, которые подтягивают её как зависимость. Если установка откладывается, разумно изолировать разбор недоверенных документов в отдельные процессы с урезанными правами. Полезно также не запускать разбор в том же процессе, где работают остальные потоки сервиса. Проверить наличие уязвимой версии помогают системы учёта зависимостей и перечни компонентов сборки.
Проблема в libextractor повторяет закономерность последних лет. Библиотеки для разбора форматов получают данные напрямую от пользователя, и службы безопасности проверяют их реже. Обновляют такие компоненты медленнее, чем прикладное программное обеспечение, а зависимость от них косвенная. Потому проверка состава зависимостей и скорость установки исправлений дают больше, чем разовые меры вроде сетевых фильтров. Пока библиотека остаётся в сборке, файл от незнакомого отправителя несёт риск для всего сервиса, а не только для одного документа.
Ссылки
- https://www.gnu.org/software/libextractor/
- https://git.gnunet.org/gnunet/libextractor/commit/2781c7e9095f4ddaff4f535d69342f3903b18422.html
- https://github.com/Haitam-lazaar/libextractor-ole2-rce
