1 (25.09.2014 10:16:42 отредактировано lone_wolf)

В командном интерпретаторе Bash выявлена опасная уязвимость (CVE-2014-6271), позволяющая организовать выполнение кода в контексте другого сеанса bash. Проблема вызвана недоработкой в организации экспорта переменных окружения и shell-функций в другие экземпляры bash, что приводит к выполнению блоков кода из специально оформленных переменных окружения, полученных от других процессов.

   Во многих типовых конфигурациях уязвимость может быть эксплуатирована по сети, если bash вызывается в качестве shell-интерпретатора. Потенциально может быть атаковано любое приложение которые запускает bash или скрипты на bash с установкой переменных окружения на основе внешних данных (манипуляция с подобными suid-программами может привести к повышению привилегий в системе). В том числе могут быть атакованы CGI-скрипты (написанные на bash или в которых вызывается bash), dhclient, CUPS и конфигурации OpenSSH.

   Текущие версии bash используют переменные окружения для экспорта функций, при этом если в переменной содержится "() {", то её содержимое воспринимается как функция. Из-за ошибки, после завершения тела функции, обработка продолжается и после символа "}". Если после функции указана команда, то bash выполнит и её (например, "VAR=() { ignored; }; /bin/id"). Уязвимость проявляется для любых переменных окружения, имя не имеет значения.

В случае с OpenSSH атака может быть проведена через подстановку переменной окружения SSH_ORIGINAL_COMMAND:

 Консоль:
   ssh -o 'rsaauthentication yes' 0 '() { ignored; }; /usr/bin/id'

После выполнения указанной команды в переменную окружения будет скопирована в том числе строка '() { ignored; }; /usr/bin/id', которая инициирует запуск команды /usr/bin/id на стороне удалённой системы. Аналогичные атаки могут быть проведены через переменную окружения TERM или при запуске CGI-скриптов через переменные REMOTE_USER, HTTP_CUSTOM, QUERY_STRING и т.п. (например, можно передать значение "() {" вместо имени пользователя или в теле HTTP-заголовка "Custom:").

   Для устранения проблемы подготовлена серия патчей. Обновления пакетов с bash уже выпущены для Debian, Ubuntu, RHEL, CentOS. Оценить появление обновлений для других систем можно на следующих страницах: Fedora, openSUSE, SLES, Slackware, Gentoo, OpenBSD, NetBSD, FreeBSD. (p.s. В Slakware уже есть обнова)

Для проверки системы на наличие уязвимости можно выполнить команду:

 Консоль:
  env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"

В качестве обходного временного пути защиты может быть применена блокировка по маске через iptables:

 Консоль:
  iptables using -m string --hex-string '|28 29 20 7B|'


Новость взята c opennet

Спросить - стыд минуты, не узнать - стыд всей жизни

2 (25.09.2014 11:21:58 отредактировано stranger)

lone_wolf пишет:

Для проверки системы на наличие уязвимости

 Консоль: user
[user@linuxforum.tech ~]$ env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Таки это говорит о том, что её нет?

lone_wolf пишет:

если в переменной содержится "() {"

Ну так без пробела? тогда:

 Консоль: user
[user@linuxforum.tech ~]$ env x='(){ :;}; echo vulnerable'  bash -c "echo this is a test"
this is a test

Что-то я запутался, помогите знатоки bash!

3

в debian 6 уже прикрыли  ab

4

Даже патченные версии все равно уязвимы, насколько я понимаю

5

stranger пишет:

Таки это говорит о том, что её нет?

файлика при этом не создается в текущей директории?

6 (25.09.2014 12:04:14 отредактировано stranger)

alexfinn пишет:

файлика при этом не создается в текущей директории?

Точно нет. И да, писать-то таки без пробела, как сказано изначально или с пробелом, как в приведённой строке?

7

при запуске вот этого:

X='() { (a)=>\' bash -c "echo date"

в директории получается файлик и именем echo и датой внутри

8

alexfinn пишет:

при запуске вот этого:

Ага! Разобрались. Да. Создался, содержит дату. И о чём это нам говорит, о наличии уязвимости или об отсутствии?

9

ab типа, все еще о наличии

10

alexfinn, спасибо (плюсанул)! Будем ждать...

11

alexfinn пишет:

Даже патченные версии все равно уязвимы, насколько я понимаю

под centos рабтает, а вот под debian нет

cat /etc/redhat-release
CentOS release 6.5 (Final)


rpm -aq|grep bash
bash-4.1.2-15.el6_5.1.x86_64

...
env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu Sep 25 13:00:19 MSK 2014

+

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.6 (wheezy)
Release:        7.6
Codename:       wheezy

dpkg -l|grep bash
ii  bash                               4.2+dfsg-0.1                  amd64        GNU Bourne Again SHell

 env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory
It is good day to die ...
MS Windows 10
Заметки о главном...

12

на Центе 7 работает, на Убунте 14.04 - нет... это на данный момент

13 (25.09.2014 13:28:10 отредактировано Cruiser78)

Ну и в чем её опасность? Есть очень простые вопросы:
1. Если юзеру можно, к примеру, запустить команду date, или какую иную, в интерактивном режиме, то в чем опасность, если оно запуститься с использованием выявленной "уязвимости"? По моему в этом случае опасность несколько преувеличена.
2. Если мы хотим исполнить какую-либо на удаленном компьютере, через ssh, то вначале надо авторизоваться так или иначе в ssh. Верно? И только затем наша команда исполнится. Верно? Тогда какая нафиг разница, как именно передать имя команды на удаленный компьютер, традиционным способом или вновь выявленным в переменной окружения? Результат будет одинаков - команда исполнится при условии, если её исполнение разрешено данному юзеру. А если не разрешено, если не вписано, например, в sudoers, то как поднять полномочия (применить sudo на команду) исполнения?

Так что никакой особой опасности в данной "уязвимости" я пока не усматриваю. Так как будут исполняться только те команды, которые юзер (который должен перед этим легально зарегистрироваться в системе) и сам имеет право исполнять. То есть данную уязвимость скорее можно отнести к разряду Сам Себе Злобный Буратино, чем реально атакующей вещи.

14

Тем линуксы мне и нравятся, найдена уязвимость - все бросились проверять (что правильно -  бережем свои сервачки)  ab

15

Bif пишет:

найдена уязвимость - все бросились проверять

это свойственно всем нормальным админам(*nix,win etc.)

It is good day to die ...
MS Windows 10
Заметки о главном...

16

alexfinn пишет:

на Центе 7 работает, на Убунте 14.04 - нет... это на данный момент

В Ubuntu/Debian sh сомтрит на dash, в котором уязвимости нет.

Там работает так:

 Консоль:
env X='() { (a)=>\' bash -c "echo date"; cat echo

Cruiser78 пишет:

Так что никакой особой опасности в данной "уязвимости" я пока не усматриваю.

http://www.opennet.ru/opennews/art.shtml?num=40670
И вообще любой сервис, который изменяет переменные окружения и дергает какие-то bash скрипты, теоретически уязвим.

17

да, это я позабыл совсем про dash

18 (25.09.2014 15:03:21 отредактировано xxblx)

alexfinn пишет:

при запуске вот этого:

X='() { (a)=>\' bash -c "echo date"

в директории получается файлик и именем echo и датой внутри

alexfinn пишет:

ab типа, все еще о наличии

Че-то я вообще ничего не понял.
Выполняю

X='() { (a)=>\' bash -c "echo date"

Файл с названием echo создается. Это говорит о том, что уязвимость есть, верно?

Но при этом мне минувшей ночью пришло обновление якобы с фиксом: http://advisories.mageia.org/MGASA-2014-0388.html
Как-то это странно.

Fedora GNOME3

19

xxblx пишет:

Файл с названием echo создается. Это говорит о том, что уязвимость есть, верно?

Ага.

xxblx пишет:

Но при этом мне минувшей ночью пришло обновление якобы с фиксом: http://advisories.mageia.org/MGASA-2014-0388.html
Как-то это странно.

Обновление решило проблему только частично.

20 (25.09.2014 15:15:22 отредактировано xxblx)

neol, а вот если выполнить команду из шапки топика

env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"

ничего не создается тогда.
Похоже да, проблема частично решена.

Fedora GNOME3

21

xxblx пишет:

Похоже да, проблема частично решена.

Так и есть

22

В продолжении темы: Вести.net: Shellshock оставил беззащитным Интернет

+ скрипт для проверки:

https://github.com/hannob/bashcheck/blo … /bashcheck

It is good day to die ...
MS Windows 10
Заметки о главном...

23

Fedora 20

$ sh bashcheck
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs

Жить можно ab

24

 Консоль: root
[root@linuxforum.ru ~]# bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./test: line 15:  8606 Ошибка сегментирования                   bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)

И какие выводы я должен из этого сделать?

25

Обновить bash, пнуть маинтейнеров bash в твоём дистрибутиве.

26

Vascom пишет:

Обновить bash, пнуть маинтейнеров bash в твоём дистрибутиве.


Это только что обновлённая. Майнтейнеров пинать бестолку, сами проснутся, но волнует другое:

 Консоль:
line 15:  8606 Ошибка сегментирования                   bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null

27

Это и есть баг.

28

Vascom, ну вот теперь понятно, спасибо!

29

openSUSE13.1

Сведения — пакет bash:
----------------------
Репозиторий: shells
Имя: bash
Версия: 4.3-14.1

 Консоль:
verg@localhost:~> sh bashcheck     
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs

30

Mageia 4 со всеми обновлениями.

 Консоль:
[xxblx@localhost ~]$ ./bashcheck
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./bashcheck: line 18:  7209 Ошибка сегментирования                   bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)

Пожалуй, отпишусь в баг-трекер дистрибутива ab

Fedora GNOME3