Как использовать переменную ENV ПУТИ для чтения/etc/shadow файла, являющегося обычным пользователем

Таким образом, это было проектом, который я получил, и я - застрявшая половина пути.

В большинстве дистрибутивов Linux (Fedora и включенная Ubuntu), /bin/sh на самом деле символьная ссылка на /bin/bash. Для использования zsh мы должны связаться /bin/sh кому: /bin/zsh. Следующие инструкции описывают, как изменить оболочку по умолчанию на zsh:

  • войдите в систему как корень
  • cd /bin
  • rm sh
  • ln –s zsh sh

system(const char *cmd) библиотечная функция может использоваться для выполнения команды в рамках программы. Путь system(cmd) работы должны вызвать /bin/sh программа, и затем позволила программной оболочке для выполнения cmd. Из-за вызванной программной оболочки, звоня system() в UID набора программа чрезвычайно опасна. Это вызвано тем, что фактическое поведение программной оболочки может быть затронуто переменными среды, такой как PATH; эти переменные среды находятся под контролем пользователя. Путем замены этих злонамеренные пользователи могут управлять поведением программы UID набора.

Программа UID набора ниже, как предполагается, выполняется /bin/ls команда; однако, программист только использует относительный путь для команды ls, а не полный путь:

int main() 
{
    system("ls"); return 0;
}

Вход в систему как корень, запишите эту программу в названный файл bad_ls.c, скомпилируйте его (использование gcc –o bad_ls bad_ls.c) и скопируйте исполняемый файл как программу UID набора в /tmp с полномочиями 4755.

Действительно ли это - хорошая идея позволить обычным пользователям выполниться /tmp/bad_ls программа (принадлежавший корню) вместо /bin/ls? Опишите нападение, которым обычный пользователь может управлять PATH переменная среды для чтения /etc/shadow файл.

Я успешно изменил оболочку по умолчанию на zsh, создали исполняемый файл bad_ls, и скопированный это в /tmp с идентификатором 4755 разрешения.

Опишите нападение, которым обычный пользователь может управлять PATH переменная среды для чтения /etc/shadow файл.

Это - то, где я застреваю.

После выполнения bad_ls файл, я изменяюсь PATH огибающая Переменная для указания на текущий каталог при помощи кода

export PATH =.:$PATH 

Если я работаю ls -a /etc/shadow, все, что я получаю, является этим: /etc/shadow

Я был бы действительно благодарен, если Вы могли бы вести меня в этой проблеме.

1
задан 17 October 2016 в 01:21

1 ответ

Проблемой является этот случай, это system("ls") работал бы, какой бы ни исполняемый файл назвал ls это находит сначала в наборе пользователя PATH.

Это ls должен не обязательно перечислить содержание каталога. Вместо этого это мог быть сценарий как это:

#!/bin/sh
cat /etc/shadow

Скажем, Вы помещаете этот сценарий куда-нибудь в каталог ниже Вашего корневого каталога, например /home/datashark/bin и добавьте это к Вашему PATH:

PATH="/home/datashark/bin:$PATH"

Если Вы теперь работаете ls, Вы не получите список каталогов, вместо этого Вы получите сообщение об ошибке:

cat: /etc/shadow: Permission denied

Но если Вы работаете bad_ls, system("ls")- вызов там будет также искать названный исполняемый файл ls в Вашем PATH и найдите и /home/datashark/bin/ls вместо /bin/ls. Как bad_ls выполнения с поднятыми корневыми полномочиями, сценарий называют ls будет (в определенных системах - видят ниже), также выполненный с поднятыми корневыми полномочиями, и команда - также cat /etc/shadow, который распечатает содержание /etc/shadow.

Таким образом, это - плохая идея для корня для разрешения выполненным обычным пользователям bad_ls пока это имеет полномочия SUID, потому что это запустило бы любую названную программу ls это на первом месте в пользователе PATH.


Примечание:

Это не работает над каждой системой Linux. Например, это не будет, согласно man 3 system, работа над системами, где /bin/sh или связывается с (неисправленный) bash из версии 2 или более новый (2.0 был выпущен в 1996). bash полномочия отбрасываний на запуске. Это не только производит ls сценарий, но также и вызов system() прежде, как system() передает команду /bin/sh.

Это может работать над другими дистрибутивами, которые не используют bash как /bin/sh. Вопреки информация, указанная в проекте, Ubuntu (как Debian и вероятно большинство производных любого) использование dash и нет bash как /bin/sh и делал поэтому начиная с версии 6.10 (с 2006! Посмотрите эту страницу в Wiki Ubuntu). Кажется этим с последними версиями Ubuntu (по крайней мере 16,04) dash и поэтому /bin/sh исправляются для автоматического отбрасывания полномочий SUID (Ищите "priv" в man dash).

1
ответ дан 7 December 2019 в 15:46

Другие вопросы по тегам:

Похожие вопросы: