Срочное исправление bash. Критическая уязвимость.

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

Как уязвимость может затронуть пользователя?

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

Создать переменную окружения можно следующим образом:
· Установить удаленное соединение через SSH и попробовать войти в систему. Подобрав специфический логин или имя хоста, можно создать переменную окружения со специфическими данными;
· Вынудить пользователя создать переменную окружения самостоятельно;
· Вынудить определенные программы задать нужное значение переменной окружения. К примеру, пользователь запустил web-сервер и скрипт, устанавливающий собственную переменную окружения. Даже несмотря на то, что работа скрипта не изменяет системные переменные окружения, ОС уже уязвима.

Установив собственную переменную окружения, хакеры смогут выполнить произвольный код на устройстве пользователя при следующем запуске bash. Ситуация может стать еще опаснее при использовании команды sudo –s, запускающей bash с корневыми правами.

Отметим, что некоторые программы используют bash для совершения собственных операций. Даже если пользователь не использует bash, его ПК уже может быть уязвим.

Для того чтобы проверить, уязвима ли система, следует выполнить в терминале команду:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Если система пользователя защищена, bash вернет следующее сообщение:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

Если система пользователя уязвима, bash вернет следующее сообщение:
vulnerable
hello

Исправление
Разработчики Bash выпустили срочное исправление, устраняющее эту уязвимость. Всем пользователям ОС Linux (особенно дистрибутивов Ubuntu и Debian) рекомендуется как можно скорее загрузить последние обновления для данного программного продукта.

URL производителя:  http://ftp.gnu.org/pub/gnu/bash/

Решение:  Установите последнюю версию 4.3 с сайта производителя.

Ссылки:  http://seclists.org/oss-sec/2014/q3/649

Source: www.securitylab.ru

Xoma55

2014-09-26 11:17:25

Скачал версию 4.3 с сайта производителя. Собрал, установил... уязвимость не исчезла =_=

Debian Wheezy

root@xxxx:~# $SHELL --version

GNU bash, version 4.3.0(1)-release (x86_64-unknown-linux-gnu)

root@xxxx:~# env x='() { :;}; echo vulnerable' bash -c 'echo hello'

vulnerable

hello

root@xxxx:~#

ЧЯДНТ?

LENS

2014-09-26 11:23:46

[root@srv~]# env x='() { :;}; echo vulnerable' bash -c 'echo hello'
hello

Вот такая у меня ситуация

DarkSpider

2014-09-26 12:16:24

Версия 4.3.0 от 26-Feb-2014

Там еще свежий патч есть:

bash43-025 24-Sep-2014

Xoma55

2014-09-26 13:05:19

Да, с патчем все прокатило, спс.

root@xxxx:~# env x='() { :;}; echo vulnerable' bash -c 'echo hello'

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

hello

root@xxxx:~#

DarkSpider

2014-09-26 13:14:28

А как патч накладывали ? У меня не получилось.

cd /install/bash/bash-4.3
wget http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025
patch -p0 ./bash43-025

и все...

UPD. Разобрался :

patch -p0 < ./bash43-025

Xoma55

2014-09-26 13:21:49

ложим патч в корневую папку

patch -p0 < bash43-025

DarkSpider

2014-09-26 13:29:21

Спасибо, нашел уже.

Профтыкал знак <

Abram

2014-09-26 13:54:59

Кто вообще в бинарных дистрибутивах собирает из тарболов такие вещи, как bash? :-/

Xoma55

2014-09-26 14:19:35

А что делать если в репах лежит старый пакет с дырой в безопастности? Из всех дистрибов только Ubuntu оперативно отработал.

Abram

2014-09-26 14:36:44

А что делать если в репах лежит старый пакет с дырой в безопастности? Из всех дистрибов только Ubuntu оперативно отработал.

Конкретно в этом случае - взять source-пакет из дистрибутива, пропатчить, собрать пакет, установить.

Конкретно в вашем (Debian ведь?) - взять готовый патченый source-пакет из ближайшей к вам версии ubuntu, собрать пакет, установить.

Kto To

2014-09-26 19:48:49

Как интересно удаленно вы собираетесь запустить bash на какой-либо системе не имея логина и пароля к ней для доступа по телнет/ссш?

graysilver

2014-09-26 19:59:21

hint: cgi

ttttt

2014-09-26 20:08:26

Как вариант решения проблемы - установите dash и замените симлинк/хардлинк /bin/sh на него. Проблема ж именно в том, что там симлинг на bash, а сам bash нигде в общем-то не используется.

Lynx100

2014-09-27 01:59:45

hint: cgi

это если есть cgi на шеле

ttttt

2014-09-27 02:23:55

это если есть cgi на шеле

Неа, дело не в этом. Пример для линукса (или truss вместо strace для freebsd):

strace -F perl -le 'print `echo "foo"`' 2>&1 | grep "/bin/sh"

У вас могут бэкапы делаться, базы дампиться, юзеры добавляться, да что угодно через вэб на сервере может управляться и все это может проходить через /bin/sh, хоть cgi, хоть нет.

Lynx100

2014-09-27 02:28:20

это если есть cgi на шеле
Неа, дело не в этом. Пример для линукса (или truss вместо strace для freebsd):
strace -F perl -le 'print `echo "foo"`' 2>&1 | grep "/bin/sh"
У вас могут бэкапы делаться, базы дампиться, юзеры добавляться, да что угодно через вэб на сервере может управляться и все это может проходить через /bin/sh, хоть cgi, хоть нет.

этот пример работает потому что есть обратные скобки `` - которые в перле вызывают sh

ttttt

2014-09-27 02:37:57

Ну вот типичная ситуация: скрипт на коленке что-то автоматизирует, выполняет команды и сам запускается из под CGI, соответственно получает http-заголовки через переменные окружения, которые передаются процессу /bin/sh, который выполняет те команды. Если /bin/sh симлинком на bash - атакер может через GET запрос со специальным заголовком выполнить хоть rm -rf /

ttttt

2014-09-27 02:41:12

Кстати не только CGI, распространяется и на FastCGI и подобные, которые на каждый HTTP запрос заполняют переменные окружения его заголовками.

Lynx100

2014-09-27 02:47:41

Ну вот типичная ситуация: скрипт на коленке что-то автоматизирует, выполняет команды и сам запускается из под CGI, соответственно получает http-заголовки через переменные окружения, которые передаются процессу /bin/sh, который выполняет те команды. Если /bin/sh симлинком на bash - атакер может через GET запрос со специальным заголовком выполнить хоть rm -rf /

если не юзать `` - а например через system, exec или open - то sh не будет вызываться.... и соответственно ничего страшного не будет тоже

можете проверить на вашем же примере только поменять вызов `` на system или exec

ttttt

2014-09-27 02:56:23

если не юзать `` - а например через system или open

По идее перл не вызывает шелл, только если знает, как это запустить без шелла, а в остальных случаях всегда вызывает. И пофиг через system или через open или через ``. Можете проверить с чем-то посложнее, чем echo, например system("echo foo | grep foo")

Lynx100

2014-09-27 03:06:45

если не юзать `` - а например через system или open
По идее перл не вызывает шелл, только если знает, как это запустить без шелла, а в остальных случаях всегда вызывает. И пофиг через system или через open или через ``. Можете проверить с чем-то посложнее, чем echo, например system("echo foo | grep foo")

вы не совсем правы

exec

Выполняет заданную параметром СПИСОК команду, прекращая дальнейшее выполнение программы Perl. Никогда не возвращает кода возврата выполнения команды, только в случае, если команда не существует, возвращает булево значение Ложь. Если СПИСОК состоит более чем из одного элемента, вызывает системную команду execvp(3) и передает ей в качестве параметров значения списка, которая вызывает заданную первым элементом списка команду, интерпретируя оставшиеся элементы как ее параметры. Если список представлен одной скалярной переменной или массивом из одного элемента, то его значение проверяется на наличие метасимволов командного интерпретатора shell. Если таковые обнаружены, то вся строка передается анализатору shell(в Unix это /bin/sh -c); в противном случае она разбивается на слова и передается в качестве параметра системной команде execvp(). В системной переменной $0 сохраняется имя выполняемой команды. В форме с параметром ПРОГРАММА выполняет команду, заданную этим параметром, а в системную переменную $0 заносится содержимое первого элемента списка. Таким образом можно скрыть от программы Perl имя истинной выполняемой команды.

system

Аналогична функции exec(), но для выполнения команды порождает новый процесс, окончания которого ожидает родительский процесс, прежде чем продолжить свое выполнение. Все, что сказано относительно параметров функции exec(), распространяется и на параметры функции system(). Возвращает такой же код завершения команды, что и функция wait(); для получения истинного кода завершения полученное значение следует разделить на 256.

а обратные кавычки всегда запускают шелл

т.е. если нормально писать CGI то ничего страшного не будет...

ttttt

2014-09-27 03:46:11

Метасимволы - это еще хуже, это значит, что никто реально не сможет сказать, когда у них вызывается шелл в коде, потому что никто не помнит те метасимволы. Захотел передать аргумент с пробелом и получить построчный вывод в массив - метасимвол тут как тут и утилитка вызывается через шелл, а не напрямую через execve(). И вообще все это излишняя сложность, она к добру не ведет. Вон вы даже ошибаетесь на счет когда шелл вызывается в обратных кавычках, а смело судите о том, как это ниче страшного и существует какое-то "нормально писать". Не существует, перестаньте заблуждаться, и всякий вызов шелла можно встретить в очень неожиданных местах.

Безопасность - это вообще очень тяжело. Очень-очень. Настолько, что у всех здесь на форуме вся инфраструктура обычно сильно страшно дырявая, а только иногда просто дырявая. Но при этом большинство считает, что у них все ок.

Я тут как-то предупреждал людей не светить ssh наружу, минимум с белых списков /etc/hosts.allow начинать. Но меня по-моему никто адекватно не воспринял. Пока очередная зиродэй уязвимость в ssh не всплыла, мало кто даже задумался.

Так и сейчас. Уязвимость особенно страшная для админов из-за типичной админской автоматизации, а кто-то еще спорит, что нет. Не гоните.

Kto To

2014-09-27 10:09:16

Проблема я так понимаю сугубо на линухе где /bin/sh симлинком на баш?

ttttt

2014-09-27 13:29:55

Проблема я так понимаю сугубо на линухе где /bin/sh симлинком на баш?

Да.

Prihod

2014-10-02 23:39:38

[root@srv~]# env x='() { :;}; echo vulnerable' bash -c 'echo hello'

hello

Вот такая у меня ситуация

После обновления у меня тоже самое выдает

DarkSpider

2014-10-03 07:47:57

После обновления у меня тоже самое выдает

Внимательно ветку читали ?

Еще нужно последний патч наложить.

sov

2014-10-03 09:46:52

Проблема я так понимаю сугубо на линухе где /bin/sh симлинком на баш?

На FreeBSD у меня тоже была уязвимость. Убедился в её наличии. Обновил баш. Уязвимость пропала.

Prihod

2014-10-06 14:38:31

После обновления у меня тоже самое выдает

Внимательно ветку читали ?

Еще нужно последний патч наложить.

Патчи наложил все, вплоть до 28-го

You should to log in

Password

Remember me