Уязвимость кода

Question

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

setresuid(geteuid(), geteuid(), geteuid()); 
system("/usr/bin/id"); 

FWIW, я не вижу. Я знаю, что setresuid установит uid владельцу файла, но я не могу изменить владельца никому, кроме меня. Я думал о попытке перенаправить команду id, изменив PATH, но поскольку он использует абсолютный путь, этот трюк не работает. Подсказки?

Answer 1

Можно использовать неясный (и теперь исправленный) вопрос с участием непроверенного использования setresuid():

1. Под Linux 2.6 и более поздней setresuid() могут потерпеть неудачу, если процесс запущен с RLIMIT_NPROC (то есть предел количества процессов, заданного ulimit -n), так что для целевого UID было бы слишком много процессов, если бы удалось выполнить setresuid().

   Однако в Linux 3.1 и более поздних версиях ошибка setresuid() устанавливает флаг процесса, при котором последующие вызовы execve() не будут выполнены. Это предотвратит запуск system() на любом современном Linux, если ошибка setresuid().

2. Если не существует более крупного контекста, который был опущен, возможно установить переменные среды (например, LD_PRELOAD), которые вызывают ввод кода в /usr/bin/id. Эти переменные игнорируются для исполняемых файлов setuid, но не будут проигнорированы для исполняемых файлов, запущенных , исполняемый файл setuid, как это происходит здесь.

Если вы находитесь на уязвимой системе (Linux 2.6 через 3.0), вы можете быть в состоянии использовать эту уязвимость путем установки переменных окружения и вызывая setresuid() на провал, так что /usr/bin/id работает указанный пользователем код в качестве корня ,

Answer 2

Функция system() выполняет команду, заданную в качестве аргумента, передавая ее /bin/sh -c. Я думаю, что программа /usr/bin/id не имеет особого значения; это ключевое слово оболочки. В частности, обратите внимание, что поведение запуска командной оболочки отличается, когда реальный и эффективный UIDs отличаются:

Если оболочка запускается с эффективным пользователя (группы), не совпадающим с реальным пользователем (группа) ID [. ..] нет загрузочных файлов, функции оболочки не наследуются от среды, переменные SHELLOPTS, BASHOPTS, CDPATH и GLOBIGNORE, если они отображаются в среде, игнорируются, а эффективный идентификатор пользователя устанавливается на реального пользователя Я бы.

- BASH 4.1 ручной

В том случае, если программа, содержащая код, который вы представленный установлен SUID, код предотвращает условия, приведенные в этом пункте от применения путем установления реальной, эффективной, и сохраненные UIDs все равны эффективному UID (который будет UID владельца исполняемого файла).

Эксплуатации обычно вращаются вокруг небезопасного использования ненадежных данных, причем переменные окружения являются частыми нарушителями.В переменной среды ENV в частности указывается файл, который при некоторых обстоятельствах оболочка будет выполняться при запуске. bash не запускает его, когда реальный и эффективный UID отличаются, как описано в выдержке выше, но в противном случае это сделает при вызове интерактивно в режиме совместимости с POSIX или как sh.

Это не помогает для неинтерактивного вызова, как это применимо здесь, поэтому теперь мне нужно идти спекулятивно. I подозреваемый, но в настоящее время не может документировать, что некоторые другие прошлое - и, возможно, даже настоящие - версии оболочки do выполняют команды чтения и выполнения из файла с именем ENV при вызове неинтерактивно. Это обеспечило бы вектор для выполнения произвольных команд в качестве владельца программы setuid.

В слабой поддержке этой спекуляции я направляю свое внимание на BASH_ENV переменную, которая аналогична ENV, но используется, когда bash вызывается не в интерактивном режиме, так как bash. Я полагаю, что, как только эти две переменные были более параллельными, применимы как к интерактивным, так и к неинтерактивным режимам, но неинтерактивное использование ENV и интерактивное использование BASH_ENV были удалены в разное время. по разным причинам. Вполне возможно, что неинтерактивное использование ENV было удалено, чтобы подключить точно отверстие, которое вы ищете.