Адрес: ул. Б. Очаковская 32 Москва Россия
Наши официальные канал и чат в telegram
Поднимем Devuan на вершину Distrowatch! Просто перейдите по ссылке один раз в день.

Уязвимости в apport и systemd-coredump, позволяющие извлечь хэши паролей пользователей системы

Новости собранные из разных RSS источников
Аватара пользователя
root:#
Site Admin
Сообщения: 275
Зарегистрирован: Вт ноя 08, 2022 3:27 pm
Благодарил (а): 39 раз
Поблагодарили: 22 раза

Уязвимости в apport и systemd-coredump, позволяющие извлечь хэши паролей пользователей системы

Сообщение root:# »

Уязвимости в apport и systemd-coredump, позволяющие извлечь хэши паролей пользователей системы
Компания Qualys выявила две уязвимости в инструментах apport (CVE-2025-5054) и systemd-coredump (CVE-2025-4598), применяемых для обработки core-файлов, генерируемых после аварийного завершения процессов. Уязвимости позволяют получить доступ к core-файлам, сохранённым после аварийного завершения suid-приложений или некоторых системных фоновых процессов, в памяти которых могут содержаться прокэшированные учётные данные или ключи шифрования. Утилита apport автоматически вызывается для сохранения core-дампов в Ubuntu, а systemd-coredump в Red Hat Enterprise Linux 9+, Fedora и многих других дистрибутивах Linux. Продемонстрирована техника атаки, в ходе которой создавались условия для аварийного завершения suid-приложения unix_chkpwd и получения доступа к core-файлу с дампом состояния во время краха. В сохранённом core-дампе присутствовали хэши паролей пользователей системы, остававшиеся в памяти аварийно завершившегося процесса после загрузки содержимого /etc/shadow. Возможность эксплуатации уязвимостей продемонстрирована в Ubuntu 24.04 и Fedora 40/41, но предполагается, что и другие дистрибутивы подвержены подобным атакам. Обе уязвимости вызваны состоянием гонки, позволяющем подменить аварийно завершившийся suid-процесс на другой процесс в момент после начала обработки ядром аварийного завершения, но до проверки обработчиком в пространстве пользователя параметров процесса через /proc/pid/files. Вызов apport и systemd-coredump осуществляется следующим образом: ядро, получив информацию об аварийном завершении процесса, вызывает обработчик, указанный в файле /proc/sys/kernel/core_pattern, после чего передаёт ему содержимое core-дампа через входной поток. Генерация core-дампа и запуск обработчика происходит не мгновенно и этого времени достаточно, чтобы подменить завершившийся suid-процесс на обычный процесс пользователя. В случае подмены запущенный обработчик core-дампов будет считать, что сбой произошёл не в suid-процессе, а в обычном пользовательском приложении и, соответственно, сохранит core-файл с возможностью доступа обычного пользователя, а не только администратора. Атака на apport сводится к следующим шагам:
  • Ответвляется новый процесс и вызывается функция execve() для запуска suid-программы, такой как unix_chkpwd. Пропускается время, необходимое для загрузку suid-программой конфиденциальных данных в память (в случае unix_chkpwd ожидается загрузка хэшей паролей всех пользователей системы из файла /etc/shadow). До окончания выполнения команды процессу отправляется сигнал SIGSEGV или SIGSYS для аварийного завершения. В ответ на аварийное завершение ядро формирует core-дамп и запускает процесс apport для обработки core-дампа в пространстве пользователя. После запуска apport, но до начала разбора аварийно завершившемуся процессу отправляется сигнал SIGKILL, а сам процесс заменяется на другой без флага suid. Для обхода проверок в apport новый процесс создаётся внутри отдельных пространств имён (user, pid и mount namespace). apport подключается к unix-сокету /run/apport.socket в созданном для нового процесса пространстве имён точек монтирования и отправляет файловый дескриптор для доступа к core-дампу.
Чтобы получить для нового процесса нужный идентификатор, совпадающий с идентификатором suid-процесса, до отправки сигнала SIGSEGV suid-процесс останавливается сигналом SIGSTOP и во время остановки циклично запускаются новые процессы, пока не будет получен PID с предшествующим номером, близким к подменяемому suid-процессу. После сдвига нумерации PID suid-процессу отправляются сигналы SIGSEGV и SIGCONT, после чего отправляется SIGKILL и циклично запускаются новые процессы для достижения того же PID, что и у suid-процесса. Что касается systemd-coredump, то с одной стороны проведение атаки на него проще, так как нет необходимости заменять suid-процесс на процесс в отдельном пространстве пользователя и достаточно добиться совпадения AT_UID и AT_EUID. С другой стороны systemd-coredump написан на языке Си и запускается достаточно быстро, что даёт меньше времени для подмены, в отличие от apport, который написан на Python и в процессе инициализации грузит различные pyc-файлы. Подобная проблема решается искусственным замедлением systemd-coredump - при вызове suid-файла передаётся очень большое число аргументов командной строки, что создаёт нужную задержку, возникающую во время разбора /proc/pid/cmdline. В процессе анализа уязвимостей исследователи также выявили, что systemd-coredump при настройке вызова не указывает в /proc/sys/kernel/core_pattern флаг "%d", что позволяет атакующему вызвать аварийное завершение фоновых процессов, выполняемых с правами root и ответвляющих другие процессы с изменением идентификатора пользователя на непривилегированного пользователя под которым совершается атака. Подобная возможность позволяет совершить атаку не только на setuid-приложения, но и на такие процессы, как sshd-session (OpenSSH), sd-pam (systemd) и cron, для получения осевших в их памяти конфиденциальных данных, таких как закрытые ключи, хэши паролей из /etc/shadow, канареечные метки из стека и данные для обхода рандомизации адресного пространства (ASLR). Проследить за публикацией обновлений пакетов в дистрибутивах можно на страницах: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo, Arch. В качестве обходного пути блокирования уязвимостей предлагается отключить сохранение core-дампов для suid-программ и сбрасывающих привилегии процессов, выставив параметр /proc/sys/fs/suid_dumpable в значение 0. Для полноценного устранения проблемы требуется внесение изменений в ядро Linux, реализующее возможность передачи информации об аварийно завершившемся процессе через механизм pidfd (pidfd связывается с конкретными процессами и в отличие от pid повторно не назначается).
Источник: https://www.opennet.ru/opennews/art.shtml?num=63328