проблема безопасности с set-uid и относительным путем для INTERP (динамического компоновщика) в ELF

Комбинация set-uid и относительного пути в разделе INTERP двоичного файла ELF очень опасна.

Я не совсем уверен, как и где следует сообщать об этой проблеме, но мне кажется, что это общая проблема безопасности, связанная с тем, как работает динамическая компоновка в linux/glibc, поэтому позвольте мне объяснить, что это такое:

Рассмотрите возможность создания динамически компонуемого бинарного файла и указания относительного пути в разделе ELF INTERP (используя параметр --dynamic-linker gcc), чтобы вы могли распространять пользовательскую версию glibc с вашим динамически компонуемым коммерческим приложением (где вам не разрешено статично компоновать против LGPL glibc, но вам все равно нужно, чтобы ваш двоичный файл работал в разных дистрибутивах Linux, имеющих разные версии glibc).

Если вы присвоите бинарному файлу права root и установите для него флаг set-uid, он фактически станет руткитом. Выполняя его из другого каталога, вы можете заменить исполняемый файл динамического компоновщика, который будет выполняться с правами root.

Чтобы продемонстрировать это, взгляните на следующий код C (issue.c):

#include <stdio.h> 

// 
// build with: 
//   gcc -DNAME=\"vulnarable\" -o issue -Wl,--dynamic-linker,.lib64/ld-linux-x86-64.so.2 issue.c 
//   sudo chown root issue 
//   sudo chmod u+s issue 
// now build some code to be executed with root permissions (we use the same issue.c): 
//   mkdir -p .lib64/ 
//   gcc -DNAME=\"rootkit\" -o .lib64/ld-linux-x86-64.so.2 --static issue.c 
// 

int main(int argc, char* argv[]) 
{ 
    printf("(%s) euid:%d\n", NAME, geteuid()); 
} 

Если вы сейчас выполните двоичный файл set-uid следующим образом

./issue

или даже просто делать это

ldd issue

вместо того, чтобы получить то, что вы могли бы ожидать, например:

(vulnarable) euid:0

ты получаешь:

(rootkit) euid:0

Суть в том, что вы можете заменить двоичный файл ld-linux-x86-64.so.6 чем угодно.

Подобные проблемы, по-видимому, были решены путем отказа от разрешения $ORIGIN в RPATH или игнорирования LD_LIBRARY_PATH, если установлен флаг set-uid.

Поэтому мне интересно, нужно ли игнорировать INTERP в ELF всякий раз, когда установлен флаг set-uid (т.е. с использованием динамического компоновщика по умолчанию - /lib32/ld-linux.so.2 или /lib64/ld-linux-x86- 64.so.2)?

Так что вы думаете, где это должно быть исправлено или сообщено - в glibc или в ядре?