В 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-программ — и по возможности пересобрать их с динамическими библиотеками.

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

Яндекс опроверг безграничный доступ Алисы AI к данным пользователей

Алиса AI не получит неограниченный доступ к данным смартфонов и не сможет самостоятельно заглядывать в банковские приложения. Об этом заявил руководитель группы безопасности Алисы AI и автономного транспорта Яндекса Борис Рютин.

По его словам, возможности ассистента всегда ограничены механизмами безопасности мобильной операционной системы.

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

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

Комментарий последовал после публикации о возможном обновлении правил предустановки российского ПО. По данным источников, Минцифры обсуждает предоставление системным ИИ-помощникам доступа к приложениям, уведомлениям, средствам авторизации и аппаратным функциям устройств.

Источники допускали, что Алиса AI сможет взаимодействовать даже с банковскими сервисами и другими программами, обрабатывающими конфиденциальные данные.

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

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

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