Срочное исправление 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
Источник: www.securitylab.ru
Источник: www.securitylab.ru
Xoma55
2014-09-26 12:17:25
Avatar

Скачал версию 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 12:23:46
Avatar

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

 

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

DarkSpider
2014-09-26 13:16:24
Avatar

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

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

bash43-025 24-Sep-2014
Xoma55
2014-09-26 14:05:19
Avatar

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

 

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 14:14:28
Avatar

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

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 14:21:49
Avatar

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

patch -p0 < bash43-025

DarkSpider
2014-09-26 14:29:21
Avatar

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

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

Abram
2014-09-26 14:54:59
Avatar

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

Xoma55
2014-09-26 15:19:35
Avatar

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

Abram
2014-09-26 15:36:44
Avatar

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

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

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

Kto To
2014-09-26 20:48:49
Avatar

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

graysilver
2014-09-26 20:59:21
Avatar

hint: cgi

ttttt
2014-09-26 21:08:26
Avatar

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

Lynx100
2014-09-27 02:59:45
Avatar

hint: cgi

это если есть cgi на шеле
ttttt
2014-09-27 03:23:55
Avatar

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

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

strace -F perl -le 'print `echo "foo"`' 2>&1 | grep "/bin/sh"
У вас могут бэкапы делаться, базы дампиться, юзеры добавляться, да что угодно через вэб на сервере может управляться и все это может проходить через /bin/sh, хоть cgi, хоть нет.
Lynx100
2014-09-27 03:28:20
Avatar

 

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

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

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

 

этот пример работает потому что есть обратные скобки `` - которые в перле вызывают sh
ttttt
2014-09-27 03:37:57
Avatar

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

ttttt
2014-09-27 03:41:12
Avatar

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

Lynx100
2014-09-27 03:47:41
Avatar

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

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

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

ttttt
2014-09-27 03:56:23
Avatar

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

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

 

если не юзать `` - а например через 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 04:46:11
Avatar

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

 

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

 

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

 

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

Kto To
2014-09-27 11:09:16
Avatar

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

ttttt
2014-09-27 14:29:55
Avatar

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

Да.
Prihod
2014-10-03 00:39:38
Avatar

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

hello

 

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

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

DarkSpider
2014-10-03 08:47:57
Avatar

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

 

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

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

sov
2014-10-03 10:46:52
Avatar

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

На FreeBSD у меня тоже была уязвимость. Убедился в её наличии. Обновил баш. Уязвимость пропала.
Prihod
2014-10-06 15:38:31
Avatar

 

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

 

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

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

 

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

Вы должны войти

loading