The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В Bash выявлено ещё четыре уязвимости, эксплуатируемые через переменные окружения

29.09.2014 10:06

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

Проблемы CVE-2014-7186 и CVE-2014-7187 обнаружены Флорианом Ваймером (Florian Weimer) из компании Red Hat, который сразу подготовил патч с исправлением. Проблемы вызваны некорректной обработкой операций с памятью при разборе выражений и позволяют обойти внесённые прошлыми патчами ограничения для организации выполнения кода. Кроме непосредственного устранения уязвимости патч включает и превентивную меру - вводит в обиход специальный префикс "BASH_FUNC_", при котором, в сочетании с наличием в имени суффикса "()", допускается разбор функций в переменных окружения. Для переменных не соответствующих маске "BASH_FUNC_имя()" обработка функций отключена. В связи с этим, дистрибутивы выпустили третью волну обновлений Bash, в том числе включающую привязку к именам "BASH_FUNC_имя()".

Протестировать наличие проблем CVE-2014-7186 и CVE-2014-7187 можно при помощи выражений:


   bash -c "true $(printf '</dev/null
   if [ $? != 0 ]; then
      echo -e "Vulnerable to CVE-2014-7186"
   fi

   bash -c "`for i in {1..200}; do echo -n "for x$i in; do :;"; done; for i in {1..200}; do echo -n "done;";done`" 2>/dev/null
   if [ $? != 0 ]; then
      echo -e "Vulnerable to CVE-2014-7187"
   fi

Интересно, что проблем удалось избежать в NetBSD и FreeBSD, так как после первой уязвимости сопровождающие порт с Bash полностью отключили поддержку передачи функций через переменные окружения, посчитав, что, в данном случае, безопасность важнее обратной совместимости.

Что касается пятой и шестой уязвимостей (CVE-2014-6277 и CVE-2014-6278), то их выявил Михаил Залевский (Michal Zalewski), известный польский эксперт в области компьютерной безопасности, работающий в Google. Информация о проблеме пока не придана огласке (ожидается включение исправлений в bash). Общий прогноз достаточно пессимистичен, так как при разборе кода функций в bash применяется большой универсальный пласт кода, который потенциально может предоставлять множество различных векторов для атак, так как данный код написан без оглядки на обработку данных, поступающих извне. Для решения проблемы рекомендовано использовать вышепредставленный патч Флориана с ограничением имён переменных, содержащих функции.

Кроме того, можно отметить статью разработчиков языка Perl, в которой описываются пути проявления уязвимости в perl-скриптах, запускаемых в системах, в которых bash используется как /bin/sh и $SHELL. Проблемы могут проявляться в скриптах, в которых используются вызовы system и exec без разделения аргументов или при открытии потока через open с перенаправлением вывода. Проблемы не специфичны для Perl и проявляются в любых других языках, позволяющих выполнять команды с использованием командной оболочки.

Также опубликован дополнительный анализ возможных серверных систем, в которых не исключено проведение атаки Shellshock. Кроме уже упоминавшихся атак на DHCP-клиенты, CGI-скрипты и ssh-аккаунты для Git/Subversion, в обзоре утверждается о вероятном проявлении проблемы в OpenVPN (при соединении с сервером злоумышленника), Exim, qmail, procmail, Mailfilter, SER, Phusion Passenger, Radius-серверах и службах Inetd (например, tcpserver). Не подвержены проблеме Postfix, stunnel, OpenBSD inetd и xinetd.

Дополнение 1: Доступен бинарный патч (ещё один), который можно использовать для правки исполняемого файла, когда нет возможности пересобрать его из исходных текстов или установить обновление.

Дополнение 2: Патч для ядра Linux, вырезающий "() {" из переменных окружения.

Дополнение 3: Опубликована коллекция подтверждённых и потенциально возможных прототипов атак на различные виды ПО.

  1. Главная ссылка к новости (http://lcamtuf.blogspot.ru/201...)
  2. OpenNews: Критическая уязвимость в bash, которая может привести к удалённому запуску команд (дополнено)
  3. OpenNews: Найден способ обхода патча, устраняющего уязвимость в bash
  4. OpenNews: Выпуск sysdig 0.1.89 с возможностью выявления активности, связанной с атакой через bash-уязвимость
  5. OpenNews: Фонд СПО указал, что процесс устранения уязвимости в bash подчеркнул достоинства СПО
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/40702-bash
Ключевые слова: bash
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (120) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, RomanCh (ok), 10:13, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Хорошая новость для утра понедельника!
     
  • 1.4, Гость (??), 10:18, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Патч:
    # mv /bin/bash{,-bin}
    # ln -s dash /bin/bash
     
     
  • 2.7, freehck (ok), 10:28, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если бы всё было так просто. Шеллы ведь между собой частично не совместимы, а скриптописатели так любят улучшения того или иного шелла. И "тем или иным шеллом" обычно является баш, ибо самый распространённый.
     
     
  • 3.12, бедный буратино (ok), 10:39, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Если бы всё было так просто. Шеллы ведь между собой частично не совместимы, а скриптописатели так любят улучшения того или иного шелла. И "тем или иным шеллом" обычно является баш, ибо самый распространённый.

    это у какого дистрибутива так? скажите, чтобы держаться в сторонке. наоборот, везде (где я видел), соблюдают posix sh, ибо стандарт.

     
     
  • 4.14, freehck (ok), 10:44, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Если бы всё было так просто. Шеллы ведь между собой частично не совместимы, а скриптописатели так любят улучшения того или иного шелла. И "тем или иным шеллом" обычно является баш, ибо самый распространённый.
    > это у какого дистрибутива так? скажите, чтобы держаться в сторонке. наоборот, везде
    > (где я видел), соблюдают posix sh, ибо стандарт.

    Если бы это было не так, то в debian по умолчанию шёл бы именно dash, а не bash. =(

    upd: удивительно, как в момент нажатия на кнопочку "ответить", громогласное "все" превратилось в "везде, где я видел". Это хорошо и правильно. :)

     
     
  • 5.17, Аноним (-), 10:52, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В системных скриптах Debian именно dash и используется.

        $ ls -l /bin/sh
        lrwxrwxrwx 1 root root 4 Jan 10  2014 /bin/sh -> dash

     
     
  • 6.23, freehck (ok), 11:04, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > В системных скриптах Debian именно dash и используется.
    >     $ ls -l /bin/sh
    >     lrwxrwxrwx 1 root root 4 Jan 10  
    > 2014 /bin/sh -> dash

    Ну да, конечно. А то, что debootstrap в составе минимальной системы вытягивает bash, Вас, конечно же, не смущает? Равно как и то, что в рекомендованном к использованию в debian инструментарию для добавления пользователей adduser выставлено "DSHELL=/bin/bash"?

     
     
  • 7.24, Аноним (-), 11:08, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    bash - шелл для пользователей, dash - для системных скриптов. В чём противоречие? Можете grep'нуть в /etc - увидите, что "#!/bin/sh" используется раз в 10 чаще, чем "#!/bin/bash".
     
     
  • 8.26, freehck (ok), 11:19, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хм Ну вот смотрите, вы меня тут дружно заминусовали, а между тем, Вы и сами вид... текст свёрнут, показать
     
     
  • 9.30, Аноним (-), 11:59, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я вас не минусовал Отвечал я именно вам про стандартный шелл для скриптов Да и... текст свёрнут, показать
     
     
  • 10.34, freehck (ok), 12:37, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да, пожалуй, Вы правы Я что-то не с той ноги сегодня встал ... текст свёрнут, показать
     
  • 9.84, Аноним (-), 18:02, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Кармадрочеры не нужны Держи пяток минусов ... текст свёрнут, показать
     
  • 4.38, й (?), 13:13, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Rvm давно видели? Я его использовал на suse, redhat, debubuntu -- и везде он работает только с bash. Популярная штука, между прочим.
     
  • 4.158, Michael Shigorin (ok), 13:19, 01/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Мало того -- уж если в шебанге написано bin bash, то скриптописатель, вероятно,... большой текст свёрнут, показать
     
  • 3.16, Аноним (-), 10:48, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Скриптописатели на баше? ССЗБ! Для скриптов есть Bourne Shell, к-й обязан присутствовать в любой POSIX системе и вести себя 100% одинаково. Кто пишет скрипты на баше, то сам дурак и страдать ему положено!
     
     
  • 4.21, Crazy Alex (ok), 11:01, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Далеко не всем нужны скрипты, работающие на любой POSIX-системе, и далеко не все не могут позволить себе сделать зависимостью bash. Оставляя в стороне свеженайденные уязвимости, брать вместо sh что-нибудь помощнее часто вполне разумно. Другое дело, что лучше, чтобы это был не bash, а perl, например
     
     
  • 5.39, й (?), 13:14, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Помнящие переход FreeBSD с perl4 на perl5 (а позже и его вынос из base system) нервно хихикают над вашим коментарием.
     
  • 4.31, Аноним (-), 12:02, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А если dash не дает каких-то возможностей, то писать велосипед самому? Спасибо, я лучше в таких случаях буду использовать bash. Уязвимости везде есть, панику поднимать из-за того, что нашли где-то чего-то не стоит, особенно когда нашли и исправили свои же.
     
     
  • 5.75, Аноним (-), 17:22, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А если dash не дает каких-то возможностей, то писать велосипед самому? Спасибо,
    > я лучше в таких случаях буду использовать bash. Уязвимости везде есть,
    > панику поднимать из-за того, что нашли где-то чего-то не стоит, особенно
    > когда нашли и исправили свои же.

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

     
  • 4.82, fi (ok), 17:51, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > в любой POSIX системе и вести себя 100% одинаково.

    сразу видно наивного чукотского юношу, который не клепал скрипты на Bourne Shel, который только на моей памяти менял синтаксис :))

    В системе приходилось держать до трех sh, чтоб один из них правильно сработал.

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

     
     
  • 5.87, Andrey Mitrofanov (?), 18:24, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Они заметно улучшили качество кода, что приводит их к постоянному использованию.

    захватывающе всклц кто на ком стоял впрс люто плюсую тчк

     
  • 4.114, Аноним (-), 22:12, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Скриптописатели на баше? ССЗБ! Для скриптов есть Bourne Shell, к-й обязан присутствовать
    > в любой POSIX системе и вести себя 100% одинаково. Кто пишет
    > скрипты на баше, то сам дурак и страдать ему положено!

    Ню-ню, дорогой Д'Артаньян. Как насчет HP-UX с ksh по умолчанию? Там Борна и, тем более, баша в природе нет. Или насчет AIX? М?

    Ну и, наконец, как насчет большинства из 1024 дистронаклепанных пластинок?

     
     
  • 5.128, Имя (?), 01:45, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ksh и есть разновидность Bourne Shell. Учи матчасть.
     
     
  • 6.152, PnDx (ok), 21:21, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Внезапно, у ksh (из solaris 11) оказалось иное мнение о shell-совместимости, чем у bash'а.
    Напоровшись на этот прискорбный факт (что-то с циклами afair), перестал ограничивать себя "#!/bin/sh" - 1x большинство shell-скриптов проекто-зависимы.

      Однако, использовать раскормленный bash (да хотя бы и sh|ash) для cgi etc.?
    Да там же любой чих = запуск нового процесса. (Написал как-то наколеночный сет вотч-догов на bash'е и решил больше так не делать...)

     
     
  • 7.153, Andrey Mitrofanov (?), 22:25, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Внезапно, у ksh (из solaris 11) оказалось иное мнение о shell-совместимости, чем
    > у bash'а.
    > Напоровшись на этот прискорбный факт (что-то с циклами afair), перестал ограничивать себя
    > "#!/bin/sh" - 1x большинство shell-скриптов проекто-зависимы.
    >   Однако, использовать раскормленный bash (да хотя бы и sh|ash) для
    > cgi etc.?

    Ну, работает же! %) У самого на awk-е веб-сервер написан, и, да, даже не fork, а exec из-под xinetd (в другом варианте - из-под /usr/bin/socket). И ничего. Благо не лицокнижье.

    > Да там же любой чих = запуск нового процесса. (Написал как-то наколеночный
    > сет вотч-догов на bash'е и решил больше так не делать...)

    Да, баш для обработки строк - тормоз.:D

     
  • 7.154, й (?), 23:06, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Однако, использовать раскормленный bash (да хотя бы и sh|ash) для cgi etc.?

    http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html

     
  • 3.27, Клыкастый (ok), 11:22, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    #!/bin/sh ващето. И башизмы мало кто любил. А меньше всего их любят те, у кого не только линукс.
     
     
  • 4.41, YetAnotherOnanym (ok), 13:16, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В присутствии фанбоев неприлично упоминать о существовании чего-либо, кроме линукса.
     
     
  • 5.48, й (?), 13:22, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    А много ли тут людей помнят, какой был /bin/sh, скажем, в солярке аж до 11 версии? А писали под него?
     
     
  • 6.102, Аноним (-), 20:34, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ksh93
    И таки да - писали, но потом всё накрылось.
     
     
  • 7.125, й (?), 23:08, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это с 11-ой. До 11-ой там совсем другое было, погуглите. Вкратце: там был доисторический pre-posix sh из 80-х, оставленный для bug-for-bug compatibility.

    POSIX-compatible там тоже был, но в /usr/xdg4

     
  • 4.42, й (?), 13:17, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы знаете, я уже лет пятнадцать периодически наблюдаю истерику в массах "пишите на posix sh, а не на bash, так правильно". Однако, bash-only штуки здравствуют и процветают до сих пор.
     
     
  • 5.57, Клыкастый (ok), 14:58, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    процветают. это факт. прискорбный. потому что в общем-то говорят правильно. например некие скрипты внутреннего пользования или к примеру скрипты в обвязке дистроспецифичного софта - да заради бога. а вот когда например проект (например, kamailio) внутре содержит смесь sh/bash скриптов и немеряными башизмами - это не есть гуд.
     
     
  • 6.60, й (?), 15:14, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну, раз прискорбный -- возьмите и перепишите как правильно. Оно же GPL.

    А то рассуждать в духе "они все козлы, ложить хотели на posix sh и используют bash, а это же _неправильно_" уж больно легко и неконструктивно. Повторюсь, я таких ораторов уже 15 лет наблюдаю, погоды они не делают.

     
     
  • 7.103, Аноним (-), 20:37, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Повторюсь, я таких ораторов уже 15 лет наблюдаю, погоды они не делают.

    Хе-хе :) Сейчас начнут выносить линукс сервера _тысячами_, гонка идёт кто вперед good folks or bad one :)

    Если черные шляпы гонку выиграют у многоих тут не то что "погода" испортится, им резьбу сорвут кой где :) А топом нарежут новую, но левую и на 22 :)))

     
     
  • 8.155, й (?), 23:15, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    насколько я понимаю, vunerable -- системы, где 1 bash есть линк на bin sh эт... текст свёрнут, показать
     
  • 6.86, fi (ok), 18:19, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  а вот когда например проект (например, kamailio)
    > внутре содержит смесь sh/bash скриптов и немеряными башизмами - это не
    > есть гуд.

    ну тут нечего удивительного - много народу прикладывает руку к продукту...

    В свое время делал на заказ большую систему из скриптов (а я то предлагал perl, но...) и без bash её просто невозможно было бы написать чтоб удовлетворить требования заказчика. Потом, после меня, в нее  вносили дополнения, где на простом sh, а где и на bash, собственно что можно ожидать от этого?

    зы. Мой продукт НЕ kamailio! :)))

     
  • 2.9, Аноним (-), 10:33, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > # ln -s dash /bin/bash

    Есть уверенность что в dash нет таких развеселых багов?

     
     
  • 3.76, Аноним (-), 17:24, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> # ln -s dash /bin/bash
    > Есть уверенность что в dash нет таких развеселых багов?

    Вероятность наличия в нем таких нежданчиков все же ниже на порядок, потому что это просто реализация POSIX shell, а не гибрид ежа с ужом, сделанный в попытке превратить интерактивную оболочку в полноценный мультипарадигменный ЯП.

     
     
  • 4.88, Andrey Mitrofanov (?), 18:26, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Есть уверенность
    >>?
    > Вероятность наличия в нем таких нежданчиков все же

    То есть есть _не_уверенность. Оки-доки.

     
     
  • 5.98, Аноним (-), 19:39, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > То есть есть _не_уверенность. Оки-доки.

    А вам таки нужна _уверенность_? Тогда выключите компьютер, вынесите его на помойку и удалитесь в сибирские леса жить отшельником.

     
  • 3.92, www2 (??), 18:44, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По крайней мере он значительно проще, так что и багов должно быть меньше.
     
     
  • 4.146, Аноним (-), 13:40, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > По крайней мере он значительно проще, так что и багов должно быть меньше.

    В общем, так оно и есть. К ShellShock он неуязвим by design.

     
  • 3.159, Michael Shigorin (ok), 13:34, 01/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> # ln -s dash /bin/bash
    > Есть уверенность что в dash нет таких развеселых багов?

    В процитированном сквозит уверенность в том, что /bin/dash есть...

     
  • 2.94, Аноним (-), 18:56, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не, зачем? /bin/sh -> /bin/dash, а тем кто использует /bin/bash в скриптах, оторвать руки.
     
     
  • 3.101, абрывалг (?), 19:57, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Не, зачем? /bin/sh -> /bin/dash, а тем кто использует /bin/bash в скриптах,
    > оторвать руки.

    На лоре писали что dash тоже уязвим.

     
     
  • 4.107, Аноним (-), 20:43, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > На лоре писали что dash тоже уязвим.
    > На лоре

    Весьма авторитетный источник. Особенно если учесть, что dash не умеет в функции в переменных.

     
     
  • 5.117, Аноним (-), 22:15, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> На лоре писали что dash тоже уязвим.
    >> На лоре
    > Весьма авторитетный источник. Особенно если учесть, что dash не умеет в функции
    > в переменных.

    Оно таки большая проблема? И позарез нужны ну просто каждому?

     
     
  • 6.145, Аноним (-), 13:38, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Весьма авторитетный источник. Особенно если учесть, что dash не умеет в функции
    >> в переменных.
    > Оно таки большая проблема? И позарез нужны ну просто каждому?

    Не видел, чтобы кто-то их использовал всерьез. Собственно, поэтому их отсутствие - это бонус, а не проблема.

     
  • 2.108, agaga (?), 20:48, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    apt-get update
    apt-get upgrade
    git clone https://github.com/hannob/bashcheck.git

    bashcheck/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

    sed -i~ "s/bash/dash/g" bashcheck/bashcheck

    bashcheck/bashcheck
    -e Not vulnerable to CVE-2014-6271 (original shellshock)
    -e Not vulnerable to CVE-2014-7169 (taviso bug)
    -e Not vulnerable to CVE-2014-7186 (redir_stack bug)
    -e Vulnerable to CVE-2014-7187 (nessted loops off by one)
    -e Variable function parser inactive, likely safe from unknown parser bugs

     
     
  • 3.144, Аноним (-), 13:36, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А знаете, что здесь самое интересное? То, что dash изначально был not vulnerable, и для него точно не было 0-day :)

    // Что касается CVE-2014-7187, то к группе shellshock эту уязвимость отнести нельзя, ввиду сложности ее удаленной эксплуатации.

     

     ....большая нить свёрнута, показать (49)

  • 1.6, Аноним (-), 10:22, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Всё логично - если в компоненте продукта проявляется большинство багов, они и будут продолжать появляться в ней. В Firefox это всегда был js: https://www.st.cs.uni-saarland.de/softevo/vulnerabilities.php
     
  • 1.8, Аноним (-), 10:32, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >  qmail

    Дядюшка Берштейн cpeт кирпичами от такой подставы :).

     
     
  • 2.62, tipa_admin (?), 15:33, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. По ссылке: нет bashа - нет проблемы. Там же (со слов автора) - дядюшка в курсе.
     

  • 1.10, Аноним (-), 10:34, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какая то ошибка в скрипте проверки.
     
     
  • 2.22, dead bash (?), 11:03, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    lol
     

  • 1.11, бедный буратино (ok), 10:37, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    проснулся - первым делом обнови баш
     
     
  • 2.13, Аноним (-), 10:40, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати да, в генте сегодня прилетело уже 4-е обновление его со дня, когда обнаружили первую уязвимость.
     
  • 2.106, Аноним (-), 20:41, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > проснулся - первым делом обнови баш

    s/обнови/удали/

     
  • 2.160, Michael Shigorin (ok), 13:36, 01/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > проснулся - первым делом обнови баш

    Да, перечитывал как раз недавно.  Хорошая сказка, и дядька был хороший.

     

  • 1.15, клоун (?), 10:47, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Следующая новость: "В связи с последними событиями bash переименован в resheto."
     
  • 1.19, Аноним (-), 10:57, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Вот тебе и одобреная столманом лицензия.. не защитила..
     
     
  • 2.20, Аноним (-), 11:01, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    http://www.fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-sh
     
     
  • 3.110, Аноним (-), 21:15, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    а шо отвественности нету? а чем тогда бонус GPL перед MIT ?
     
     
  • 4.135, Andrey Mitrofanov (?), 09:32, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > а шо отвественности нету?

    Хочешь ответственности? Райвоенкомат ждёт тебя! >/>>>


     

  • 1.40, solardiz (ok), 13:15, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Упомянутый патч от Florian'а, привносящий "BASH_FUNC_имя()", нейтрализует все упомянутые уязвимости (остальные патчи, включая исходный, при этом перестают быть важными для безопасности - они лишь делают парсер более надежным). Во многих дистрибутивах этот патч уже включен. Также, еще до публикации этой новости на OpenNet, мейнтейнер bash выпустил аналогичный патч для всех версий от 2.05b до 4.3 - есть на http://ftp.gnu.org/pub/gnu/bash/ (bash43-027 от 27-Sep-2014 22:38 и т.п. для других версий). Отличие от патча Florian'а в используемом суффиксе - "%%" вместо "()". Для безопасности эффект тот же, но могут быть отличия в проявлении возможных багов с обработкой тех или этих символов в других программах.

    Наконец, отключить поддержку импорта функций можно и с помощью бинарного патча: http://www.openwall.com/lists/oss-security/2014/09/29/1

     
  • 1.44, YetAnotherOnanym (ok), 13:19, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А другие скорлупки кто-нибудь проверять собирается?
     
     
  • 2.55, Нанобот (ok), 14:40, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    возможно кто-то прямо сейчас и проверяет (или уже проверил и теперь занимается прокачкой своего ботнета)
     

  • 1.45, Аноним (-), 13:20, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    ROSA тоже обновила bash
     
     
  • 2.161, Michael Shigorin (ok), 13:39, 01/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > ROSA тоже обновила bash

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

     

  • 1.47, GG (ok), 13:22, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Побежал проверять, а все дырки уже закрыты
     
  • 1.50, Аноним (-), 13:45, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Debian GNU/Linux testing, bash 4.3-9.2:

    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

     
  • 1.52, AnonymousSL (?), 14:02, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Блин, а на debian 6 так и не вышло обновление, с 7-го вручную поставил.
     
     
  • 2.70, Аскар (?), 16:59, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Загугли, как прописать в sources.list squeeze-lts, будет обновляться. На опеннете, кстати, была новость про эту самую лтс-поддержку пакетов для скуеезе.
     

  • 1.53, Аноним (-), 14:12, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хоть бы обходной путь то пофиксили. Уже 3 дня известна уязвимость. А криков про крутость опенсорса то было...
     
     
  • 2.71, edwin (??), 17:00, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Обходной путь давно известен - отключить бинарным ключом. Но онанимусы видимо Выше таких вещей  
     
  • 2.89, Andrey Mitrofanov (?), 18:37, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    2014-09-29 14:12
    >Уже 3 дня известна уязвимость. А криков про крутость опенсорса то было...

    2014-09-26 21:44  Фонд СПО указал, что процесс устранения уязвимости в bash подчеркнул достоинства СПО

    Не достаточно громко, бананы в ушах, косоглазие?

    И пока ты чего ешё не:
    2014-09-26 02:10 http://metadata.ftp-master.debian.org/changelogs//main/b/bash/bash_4.1-3+deb6
    2014-09-26 01:18 https://lists.debian.org/debian-security-announce/2014/msg00223.html

     

  • 1.54, Аноним из 9Б (?), 14:37, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    нужно срочно разработать новый,совершенный форк баша - librebash!
     
     
  • 2.56, IMHO (?), 14:57, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ты неправильно прочитал мысли Поттеринга, жди bashd
     
     
  • 3.59, manster (ok), 15:10, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    вся та затея sd - попытка заменить баш. Читая между строк, неудивительно, что букет иксплойтов вероятно будет (по унаследованным соображениям). Стоит копнуть поглубже...

    Благодаря "сквозной" архитектуре sd - будет более утончённый контроль за хостами...

     
     
  • 4.63, Andrey Mitrofanov (?), 15:48, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > вся та затея sd - попытка заменить баш.

    И все когда-либо написанные на нём. И на любых прочих шелах. И ещё немного (dhcp), и потом ещё... ///Но _питон_ РХ одбряет -- видимо, _аудитория_ импонирует.

    +++Обогнать GNU Emacs(*)! ---И сдохнуть.  (*)В SLOC-ах Си-кода.

    > Благодаря "сквозной" архитектуре sd - будет более утончённый контроль за хостами...

    "за ботнетами", вы хотели? %)

     
     
  • 5.66, manster (ok), 16:21, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Народу нужен новый баш, соответсвующий настоящим реалиям и без проблем с сабшеллами. Конечно это усложнение, но все может быть.

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

    В общем bash++ или bash-ng или bash2.0 или cash ;) - короче такой, чтобы можно было не городить сабшеллы, остальное сообразуется. Разумеется это должно быть без усложнений и ломки совместимости.

     
     
  • 6.147, Ordu (ok), 14:40, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но почему-то гентушники в портаже ебилды сделали на баше, хотя у них была возможность взять питон...

    А вы попробуйте переписать какой-нибудь баш-скрипт на питоне.

     
  • 5.139, Аноним (-), 10:30, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Слишком много неалфавитных символов.
    Xasd, перелогинься.
     
  • 4.78, Аноним (-), 17:30, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > вся та затея sd - попытка заменить баш. Читая между строк, неудивительно,
    > что букет иксплойтов вероятно будет (по унаследованным соображениям). Стоит копнуть поглубже...

    В пору конкуренции с upstart, аудиторы, нанятые канониклом, пытались найти дырки в systemd. Безуспешно.

     
     
  • 5.83, manster (ok), 17:55, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    найдут еще...

    плохо искали...

     
     
  • 6.90, Andrey Mitrofanov (?), 18:40, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > найдут еще...
    > плохо искали...

    Просто они с РХ больше взяли%))))

     
  • 6.104, Аноним (-), 20:38, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > плохо искали...

    Хорошо искали. На карты была поставлена честь корпорации и лично Марка Ш.

     
     
  • 7.136, Andrey Mitrofanov (?), 09:34, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >На карты была поставлена честь корпорации и лично Марка Ш.

    Ну, за дырки кто-то другой заплатил больше. И?

     
     
  • 8.142, Аноним (-), 13:33, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вряд ли коммерческая компания, у которой все доходы и расходы строго по ведомост... текст свёрнут, показать
     

  • 1.68, pavlinux (ok), 16:54, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лошары!

    $ ls -la /bin/sh
    lrwxrwxrwx 1 root root 4 янв 10  2014 /bin/sh -> /dev/null


    $ zcat /proc/config.gz | grep SCRIPT
    CONFIG_BINFMT_SCRIPT is not set

     
     
  • 2.72, Аскар (?), 17:03, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А в чём ты набрал команду "zcat /proc/config.gz | grep SCRIPT". и как у тебя система с \бин\ш, указывающим на \дев\нулл, вообще работает? всякие скрипты инициализационные как работают? CONFIG_BINFMT_SCRIPT=нет - это полезная штука для всяких встраиваемых систем, но с обычным линукс десктоп несовместимая
     
     
  • 3.79, Аноним (-), 17:33, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А в чём ты набрал команду "zcat /proc/config.gz | grep SCRIPT"

    Очевидно, в юзерском шелле, который прописан в passwd. Hint: кроме баша, есть и другие, более удобные и фичастые.

    > как у тебя система с \бин\ш, указывающим на \дев\нулл, вообще работает?

    Палитесь вы с обратными слешами :)

    > всякие скрипты инициализационные как работают?

    В современных линукс-системах можно обойтись и без скриптов в ините.

    > CONFIG_BINFMT_SCRIPT=нет - это полезная
    > штука для всяких встраиваемых систем, но с обычным линукс десктоп несовместимая

    Почему?

     
     
  • 4.100, абрывалг (?), 19:56, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    dash тоже уязвим.
     
     
  • 5.105, Аноним (-), 20:39, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > dash тоже уязвим.

    Во-первых, при чем тут dash? "Более удобные и фичастые" - это не про него, явно.
    Во-вторых, нет, не уязвим.

     
     
  • 6.127, vi (ok), 23:35, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> dash тоже уязвим.
    > Во-первых, при чем тут dash? "Более удобные и фичастые" - это не
    > про него, явно.
    > Во-вторых, нет, не уязвим.

    ОнониМ, ну, покажите же, ваши прелести (cat /etc/shells ;)

     
  • 4.140, Аноним (-), 10:32, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > В современных линукс-системах можно обойтись и без скриптов в ините.

    Нельзя.
    SystemdOS - не линукс.

     
     
  • 5.143, Аноним (-), 13:34, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Нельзя.
    > SystemdOS - не линукс.

    systemd/Linux, нравится вам это или нет, по факту сейчас является стандартом линукса.

     
  • 2.73, Аноним (-), 17:17, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С тапка пишешь?
     

  • 1.97, Pahanivo (ok), 19:36, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Апокалипсис грядет!!! Покайтесь!!! Все быстро переползаем на оффтоп )))
    PS хорошо что есть фря, а на фре есть sh ))
     
  • 1.109, Аноним (109), 20:50, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А томкат сервер как?  тоже уязвим?
     
  • 1.111, Аноним (-), 21:23, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    В этом весь GNU'тый софт.
     
     
  • 2.121, Аноним (-), 22:22, 29/09/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В проприетарном уязвимости признавать не выгодно - продажи падают
     
     
  • 3.138, Pahanivo (ok), 10:13, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > В проприетарном уязвимости признавать не выгодно - продажи падают

    Да, там вас просто имеют за ваши деньги, и те кто продал и те кто хакнул ))
    ПыСы и никакой паники )))

     

  • 1.112, Аноним (-), 21:48, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    плохая OpenSUSE, даже уязвимости в ней не работают(((((((
     
  • 1.113, Анонище (?), 22:11, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    hardened gentoo




    Vulnerable to CVE-2014-6271 (original shellshock)
    Vulnerable to CVE-2014-7169 (taviso bug)
    /testbashsecurity.sh: line 18:  7817 Segmentation fault      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)

    [8389100.804050] bash[7845]: segfault at 3bf129fdb0 ip 0000003b77351302 sp 00000388dee631c0 error 4 in bash[3b7732b000+c9000]
    [8389100.804073] grsec: From 2.6.1.1: (admin:S:/) Segmentation fault occurred at 0000003bf129fdb0 in /bin/bash[bash:7845] uid/euid:0/0 gid/egid:0/0, parent /testbashsecurity.sh[testbashsecurit:7840] uid/euid:0/0 gid/egid:0/0




     
  • 1.126, Igor (??), 23:24, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В Debian wheezy выполнил:
    apt-get install zsh
    chsh -s /bin/zsh username
    ...
    mv /bin/bash /bin/bak.bash
    reboot
    Все работает без багов.
    Не?
     
     
  • 2.129, soko1 (ok), 02:43, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Угу, а теперь погрепай на наличие вхождений '#!/bin/bash' в /usr/{bin|sbin} хотя бы :)
     
     
  • 3.141, Igor (??), 10:40, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Совершенно верно. Только можно и так:
    mv /bin/bash bak.bash; ln -s /bin/zsh /bin/bash
    Поскольку zsh практичвески все хавает, что на bash.
    Вот только от CVE-2014-7186 и CVE-2014-7187 к сожалению не спасает. :(
    А так все скрипты запускаются.
     
  • 2.130, Аноним (109), 03:14, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я в дебиане просто делал 'apt-get update' и 'apt-get dist-upgrade' и все что есть новое у wheezy, включая баш, он установил и все заработало :) (это на нашем веб-сервере).
     
     
  • 3.131, soko1 (ok), 03:46, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Я в дебиане просто делал 'apt-get update' и 'apt-get dist-upgrade' и все
    > что есть новое у wheezy, включая баш, он установил и все
    > заработало :) (это на нашем веб-сервере).

    Таких обновлений в дебиане было уже минимум три за пару дней. И вот-вот выйдут новые. Так что готовьтесь обновить ещё несколько раз :)

     
     
  • 4.133, Victor (??), 05:15, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Точно.  Только что выполнил обновление сервера на дебиане через 'dist-upgrade'

    Теперь уже "Not vulnerable to CVE-2014-7169 (taviso bug)"

     
  • 2.134, Аноним (-), 07:23, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    /usr/bin/zsh
     

  • 1.132, Классический Анонимус (?), 04:54, 30/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Арчик кросавчег:

    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

     
  • 1.137, Аноним (-), 09:51, 30/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Это не баг. Это фича. Так было задумано с самого начала.
     
  • 1.148, Аноним (-), 19:13, 30/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Михаил Залевский (Michal Zalewski), известный польский

    А почему не Михаль?

     
     
  • 2.149, Аноним (-), 19:15, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Или Ми́хал?
     
  • 2.150, Аноним (-), 19:18, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://pl.wikipedia.org/wiki/Micha%C5%82_Zalewski

    Michał Zalewski

    Ми́хау? :(

     
     
  • 3.151, Аноним (-), 19:19, 30/09/2014 [^] [^^] [^^^] [ответить]  
  • +/
    https://upload.wikimedia.org/wikipedia/commons/0/0c/Pl-Micha%C5%82.o
     

  • 1.156, Анжелика (?), 23:21, 30/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Понеслась звезда по кочкам.
    Сейчас начнут копаться в этом баше и еще с десяток подобных сюрпризов нароют
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру