В glibc нашли баг: setuid-программы в Linux могут выполнять чужой код

В glibc нашли баг: setuid-программы в Linux могут выполнять чужой код

В glibc нашли баг: setuid-программы в Linux могут выполнять чужой код

Исследователи сообщили об уязвимости в GNU C Library (glibc) — одной из ключевых библиотек ОС Linux. Проблема получила идентификатор CVE-2025-4802 и связана с тем, как статически скомпилированные setuid-программы загружают внешние библиотеки.

Если коротко: статические setuid-бинарники, которые по каким-то причинам вызывают dlopen() (это способ динамически загружать библиотеки во время выполнения), неправильно обрабатывают переменную окружения LD_LIBRARY_PATH. Это изъян позволяет подсовывать им вредоносные библиотеки.

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

Как это может сработать:

  • На системе есть статически скомпилированная setuid-программа.
  • Она вызывает dlopen() — напрямую или через функции типа getaddrinfo, которые под капотом используют NSS.
  • Пользователь может задать переменную LD_LIBRARY_PATH.

Самое интересное — пока что не найдено ни одного уязвимого бинарника, но эксперты предупреждают: старые или самописные утилиты вполне могут оказаться под угрозой. Особенно в организациях с «наследием».

Что делать администраторам и сборщикам дистрибутивов:

  • Обновиться до glibc версии 2.39 (или вручную вкатить патч, если у вас своя сборка).
  • Проверить, нет ли у вас статических setuid-программ — и по возможности пересобрать их с динамическими библиотеками.

Степень риска эксплуатации оценивается как низкая, но если сработает — последствия могут быть серьёзными.

Подпишитесь на новости

Киберпреступники месяцами контролировали сеть разработчика ПО в России

Группа BO Team несколько месяцев находилась в инфраструктуре российского разработчика ПО, причём ей удалось добраться до исходников и сервера подписания сборок. По оценке «Лаборатории Касперского», целью могли стать клиенты компании, поскольку атакующие получили возможность внедрить вредоносный код в её продукты.

Детали расследования эксперты опубликовали в отчёте Kaspersky ICS CERT.

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

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


Чтобы оставаться незаметными, злоумышленники старались обходиться системными утилитами, маскировали файлы под компоненты ОС, удаляли журналы и меняли временные метки.

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


По оценке экспертов, угрозу удалось нейтрализовать до достижения конечной цели.

RSS: Новости на портале Anti-Malware.ru