Не получать корневую оболочку при эксплуатации переполнения буфера

Я изучаю эксплойты переполнения буфера в двоичных файлах Linux x86. Я выполняю классическое разрушение стека, чтобы создать корневую оболочку в виртуальной машине Ubuntu 12.04, отключив ASLR и скомпилировав двоичный файл, отключив бит NX и стековые канарии.

Во время моего выполнения адрес возврата перезаписывается и выполняется шелл-код, но я не получаю корневую оболочку, вместо этого это приводит к оболочке bash.

Чтобы смягчить защиту bash, я использую оболочку zsh, удалил символическую ссылку sh->bash и создал символическую ссылку sh с оболочкой zsh в каталоге /bin.

Я пробовал с двоичным файлом с поддержкой setuid, принадлежащим root (разрешение на выполнение для другого пользователя), но все же я не получаю корневую оболочку.

Я проверил свой код оболочки с помощью программы C, а также скомпилировал тестовую программу (моего кода оболочки) и выполнил ее после включения setuid. поэтому тестовая программа дает корневую оболочку. Но я не могу получить корневую оболочку, когда тот же шеллкод используется с переполнением буфера.

Когда я отлаживаю этот сценарий в gdb, во время переполнения /bin/zsh4 запускается, но приводит к оболочке bash.

Даже я не могу получить корневую оболочку с возвратом к атаке libc. Это также приводит к оболочке bash. Я пробовал эти шаги в Ubuntu 12.04, Ubuntu 11.04 и Ubuntu9, но результат тот же.

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


person user2103885    schedule 31.03.2014    source источник
comment
Вы уверены, что двоичный файл, который вы атакуете, сам работает как root?   -  person merlin2011    schedule 31.03.2014
comment
Вы запускаете двоичный файл (с липким битом), а НЕ в gdb? Кроме того, чтобы смягчить защиту bash, я использую zsh: что вы имеете в виду (не знаком с zsh)? Какая может быть польза (порождение новой оболочки, поскольку root порождает корневую оболочку, если это вас беспокоит)? Вы пробовали использовать стандартный /bin/sh, указывающий на /bin/bash (а не на gdb)?   -  person naab    schedule 31.03.2014
comment
@ merlin2011 Я изменил права собственности на двоичный файл на root и включил для него setuid.   -  person user2103885    schedule 01.04.2014
comment
@naab, я запустил двоичный файл с включенным битом s. Я пробовал sh указывать на bash, а также на dash shell. Но я не получаю корневую оболочку. Я также могу выполнить эту атаку вне gdb, но в результате я получаю оболочку bash. Я пробовал с zsh еще и потому, что слышал, что оболочка bash и dash потеряет привилегии, если я выполню /bin/sh из программы setuid. Пожалуйста, поправьте меня, если я ошибаюсь   -  person user2103885    schedule 01.04.2014
comment
@user2103885 user2103885, я так понимаю, что двоичный файл setuid. Мой вопрос: когда вы запускаете двоичный файл, является ли оболочка, из которой вы запускаете двоичный файл, корневой оболочкой?   -  person merlin2011    schedule 01.04.2014
comment
@ merlin2011, я вызываю двоичный файл из оболочки bash.   -  person user2103885    schedule 01.04.2014
comment
@user2103885 user2103885, я слышал, что оболочка bash и dash потеряет привилегии, если я выполню /bin/sh из программы setuid. Это не совсем так, в большинстве дистрибутивов setuid отключен для скриптов (например: somescript.sh, который начинается с ведущего #!/bin/bash), а не /bin/sh для выполнения из приложения. с сетуидом. И кстати, как вы проверяете, что ваша оболочка является корневой оболочкой? я бы? кто я? (вы не обязательно получите # при получении корневой оболочки)   -  person naab    schedule 01.04.2014


Ответы (1)


Наконец-то я понял причину этой ошибки.

Во время моего выполнения моя привилегия root была удалена, потому что я отключил ptrace системного уровня процесса для работы с другим инструментом. Я перезаписал значение /proc/sys/kernel/yama/ptrace_scope на 0. Это было причиной того, что я не получил корневую оболочку.

Я нашел эту информацию на справочной странице execve (которую я использовал для создания шеллкода):

Если бит set-user-ID установлен в программном файле, на который указывает имя файла, и базовая файловая система не смонтирована nosuid (флаг MS_NOSUID для mount(2)), и вызывающий процесс не трассируется, то эффективный идентификатор пользователя вызывающего процесса изменяется на идентификатор владельца программного файла. Точно так же, когда бит set-group-ID файла программы установлен, эффективный идентификатор группы вызывающего процесса устанавливается равным группе файла программы.

Итак, теперь, когда я не отключаю ptrace_scope , я получаю корневую оболочку.

Спасибо merlin2011 и naab за участие в обсуждении.

person user2103885    schedule 01.04.2014