В дополнение к изначальной выявленной уязвимости (https://www.opennet.ru/opennews/art.shtml?num=40667) в Bash (CVE-2014-6271) и обходному методу (https://www.opennet.ru/opennews/art.shtml?num=40670) атаки (CVE-2014-7169) исследователи безопасности выявили (http://lcamtuf.blogspot.ru/2014/09/bash-bug-apply-unofficial...) ещё три уязвимости, вызванные ошибками в реализации кода разбора функций. Так как разбор функций производится в Bash для всех переменных окружения, данные уязвимости также могут быть легко эксплуатированы через формирование специального содержимого, попадающего в переменные окружения. Уязвимости в bash последние дни появляются достаточно интенсивно и многие эксперты прогнозируют (http://arstechnica.com/security/2014/09/still-more-vulnerabi.../), что не все проблемы устранены. Для комплексной проверки систем на подверженность атакам Shellshock подготовлен (https://github.com/hannob/bashcheck) универсальный скрипт.Проблемы CVE-2014-7186 и CVE-2014-7187 (http://www.openwall.com/lists/oss-security/2014/09/25/32) обнаружены (https://securityblog.redhat.com/2014/09/26/frequently-asked-.../) Флорианом Ваймером (Florian Weimer) из компании Red Hat, который сразу подготовил патч (http://www.openwall.com/lists/oss-security/2014/09/25/32) с исправлением. Проблемы вызваны некорректной обработкой операций с памятью при разборе выражений и позволяют обойти внесённые прошлыми патчами ограничения для организации выполнения кода. Кроме непосредственного устранения уязвимости патч включает и превентивную меру - вводит в обиход специальных префикс "BASH_FUNC_" при котором, в сочетании с наличием имени суффикса "()", допускается разбор функций в переменных окружения. В связи с этим дистрибутивы выпустили (http://www.ubuntu.com/usn/usn-2364-1/) третью волну обновлений Bash, в том числе включающую привязку к именам "BASH_FUNC_имя()".
Протестировать наличие проблем CVE-2014-7186 и CVE-2014-7187 можно при помощи выражений:
<font color="#461b7e">
bash -c "true $(printf '<<EOF %.0s' {1..79})" 2>/dev/null
if [ $? != 0 ]; then
echo -e "Vulnerable to CVE-2014-7186"
fibash -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
</font>Интересно, что проблем удалось избежать в NetBSD и FreeBSD, так как после первой уязвимости сопровождающие порт с Bash отключили (https://svnweb.freebsd.org/ports?view=revision&revision=369341) поддержку передачи функций через переменные окружения, посчитав, что, в данном случае, безопасность важнее обратной совместимости.
Что касается пятой и шестой уязвимостей CVE-2014-6277 и CVE-2014-6278, то их выявил (http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unofficial...) Михаил Залевский (Michal Zalewski), известный польский эксперт в области компьютерной безопасности, работающий в Google. Информация о проблеме пока не придана огласке (ожидается включение исправлений в bash). Общий прогноз пока достаточно пессимистичен, так как при разборе кода функций в bash применяется достаточно большой универсальный пласт кода, который потенциально может предоставлять множество различных векторов для атак, так как данный код написан без оглядки на обработку данных, поступающих извне. Для решения проблемы рекомендовано использовать вышепредставленный патч с ограничением имён переменных, содержащих функции.
Кроме того, можно отметить статью (http://perltricks.com/article/115/2014/9/26/Shellshock-and-Perl) разработчиков языка Perl, в которой описываются пути проявления уязвимости в perl-скриптах, запускаемых в системах, в которых bash используется как /bin/sh и $SHELL. Проблемы могут проявляться в скриптах, в которых используется вызовы system и exec без разделения аргументов или открытие потока через open с перенаправлением вывода. Проблемы не специфичны для Perl и проявляются в любых других языках, позволяющих выполнять команды с использованием командной оболочки.
Также опубликован (https://www.dfranke.us/posts/2014-09-27-shell-shock-exploita...) дополнительный анализ возможных серверных систем, в которых не исключено проведение атаки Shellshock. Кроме уже упоминавшихся атаках на DHCP-клиент, CGI-скрипты и ssh-аккаунты для Git/Subversion, в обзоре утверждается о вероятном проявлении проблемы в OpenVPN (при соединении с сервером злоумышленника), Exim, qmail (http://marc.info/?l=qmail&m=141183309314366&w=2), procmail, Mailfilter, SER, Phusion Passenger, Radius-серверы и службы Inetd (например, tcpserver). Не подвержены проблеме Postfix, stunnel, OpenBSD inetd и xinetd.
URL: http://lcamtuf.blogspot.ru/2014/09/bash-bug-apply-unofficial...
Новость: https://www.opennet.ru/opennews/art.shtml?num=40702
Хорошая новость для утра понедельника!
Патч:
# mv /bin/bash{,-bin}
# ln -s dash /bin/bash
Если бы всё было так просто. Шеллы ведь между собой частично не совместимы, а скриптописатели так любят улучшения того или иного шелла. И "тем или иным шеллом" обычно является баш, ибо самый распространённый.
> Если бы всё было так просто. Шеллы ведь между собой частично не совместимы, а скриптописатели так любят улучшения того или иного шелла. И "тем или иным шеллом" обычно является баш, ибо самый распространённый.это у какого дистрибутива так? скажите, чтобы держаться в сторонке. наоборот, везде (где я видел), соблюдают posix sh, ибо стандарт.
>> Если бы всё было так просто. Шеллы ведь между собой частично не совместимы, а скриптописатели так любят улучшения того или иного шелла. И "тем или иным шеллом" обычно является баш, ибо самый распространённый.
> это у какого дистрибутива так? скажите, чтобы держаться в сторонке. наоборот, везде
> (где я видел), соблюдают posix sh, ибо стандарт.Если бы это было не так, то в debian по умолчанию шёл бы именно dash, а не bash. =(
upd: удивительно, как в момент нажатия на кнопочку "ответить", громогласное "все" превратилось в "везде, где я видел". Это хорошо и правильно. :)
В системных скриптах Debian именно dash и используется.$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 10 2014 /bin/sh -> dash
> В системных скриптах Debian именно dash и используется.
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Jan 10
> 2014 /bin/sh -> dashНу да, конечно. А то, что debootstrap в составе минимальной системы вытягивает bash, Вас, конечно же, не смущает? Равно как и то, что в рекомендованном к использованию в debian инструментарию для добавления пользователей adduser выставлено "DSHELL=/bin/bash"?
bash - шелл для пользователей, dash - для системных скриптов. В чём противоречие? Можете grep'нуть в /etc - увидите, что "#!/bin/sh" используется раз в 10 чаще, чем "#!/bin/bash".
> bash - шелл для пользователей, dash - для системных скриптов.Хм. Ну вот смотрите, вы меня тут дружно заминусовали, а между тем, Вы и сами видите, что по умолчанию для пользователей ставится bash. По вполне понятным причинам необходимости пользователю фишек типа автодополнений bash и тому подобных, которые на dash попросту не заведутся. Вы на начало треда-то посмотрите: человек bash на dash хочет прозрачно заменить симлинком.
> Можете grep'нуть в /etc - увидите, что "#!/bin/sh" используется раз
> в 10 чаще, чем "#!/bin/bash".Но *используется*. Давайте предположим, что случится, когда тредстартер таки сделает тот симлинк? Я всего лишь пишу о том, что от баша вы так просто не отвяжетесь.
Я вас не минусовал. Отвечал я именно вам про стандартный шелл для скриптов. Да и бросьте вы переживать об этих плюсиках-минусиках.
Согласен, что заменять bash симлинком неразумно.
> Да и бросьте вы переживать об этих плюсиках-минусиках.Да, пожалуй, Вы правы. Я что-то не с той ноги сегодня встал.
Кармадрочеры не нужны. Держи пяток минусов.
Rvm давно видели? Я его использовал на suse, redhat, debubuntu -- и везде он работает только с bash. Популярная штука, между прочим.
>> Если бы всё было так просто. Шеллы ведь между собой частично не совместимы,
>> а скриптописатели так любят улучшения того или иного шелла.Мало того -- уж если в шебанге написано /bin/bash, то скриптописатель, вероятно, был грамотней в данном вопросе, чем типово-убунтушный "патч" из #4 (если бы был test -x /bin/bash, можно было бы ещё предположить дебианщика; а если бы работали по /bin/sh -- то даже грамотного).
>> И "тем или иным шеллом" обычно является баш, ибо самый распространённый.
> это у какого дистрибутива так? скажите, чтобы держаться в сторонке.
> наоборот, везде (где я видел), соблюдают posix sh, ибо стандарт.Да везде, кроме убунты с дебианом. Где dash. У которого свои тараканы, в т.ч. и по части posix -- не стоит строить иллюзий по части безглючности данного шелла.
Скриптописатели на баше? ССЗБ! Для скриптов есть Bourne Shell, к-й обязан присутствовать в любой POSIX системе и вести себя 100% одинаково. Кто пишет скрипты на баше, то сам дурак и страдать ему положено!
Далеко не всем нужны скрипты, работающие на любой POSIX-системе, и далеко не все не могут позволить себе сделать зависимостью bash. Оставляя в стороне свеженайденные уязвимости, брать вместо sh что-нибудь помощнее часто вполне разумно. Другое дело, что лучше, чтобы это был не bash, а perl, например
Помнящие переход FreeBSD с perl4 на perl5 (а позже и его вынос из base system) нервно хихикают над вашим коментарием.
А если dash не дает каких-то возможностей, то писать велосипед самому? Спасибо, я лучше в таких случаях буду использовать bash. Уязвимости везде есть, панику поднимать из-за того, что нашли где-то чего-то не стоит, особенно когда нашли и исправили свои же.
> А если dash не дает каких-то возможностей, то писать велосипед самому? Спасибо,
> я лучше в таких случаях буду использовать bash. Уязвимости везде есть,
> панику поднимать из-за того, что нашли где-то чего-то не стоит, особенно
> когда нашли и исправили свои же.Общий прогноз пока достаточно пессимистичен, так как при разборе кода функций в bash применяется достаточно большой универсальный пласт кода, который потенциально может предоставлять множество различных векторов для атак, так как данный код написан без оглядки на обработку данных, поступающих извне.
> в любой POSIX системе и вести себя 100% одинаково.сразу видно наивного чукотского юношу, который не клепал скрипты на Bourne Shel, который только на моей памяти менял синтаксис :))
В системе приходилось держать до трех sh, чтоб один из них правильно сработал.
К тому же bash имеет мощные наработки из ksh93, который сам, в чистом виде практически не встречается. Они заметно улучшили качество кода, что приводит их к постоянному использованию.
>Они заметно улучшили качество кода, что приводит их к постоянному использованию.захватывающе всклц кто на ком стоял впрс люто плюсую тчк
> Скриптописатели на баше? ССЗБ! Для скриптов есть Bourne Shell, к-й обязан присутствовать
> в любой POSIX системе и вести себя 100% одинаково. Кто пишет
> скрипты на баше, то сам дурак и страдать ему положено!Ню-ню, дорогой Д'Артаньян. Как насчет HP-UX с ksh по умолчанию? Там Борна и, тем более, баша в природе нет. Или насчет AIX? М?
Ну и, наконец, как насчет большинства из 1024 дистронаклепанных пластинок?
ksh и есть разновидность Bourne Shell. Учи матчасть.
Внезапно, у ksh (из solaris 11) оказалось иное мнение о shell-совместимости, чем у bash'а.
Напоровшись на этот прискорбный факт (что-то с циклами afair), перестал ограничивать себя "#!/bin/sh" - 1x большинство shell-скриптов проекто-зависимы.Однако, использовать раскормленный bash (да хотя бы и sh|ash) для cgi etc.?
Да там же любой чих = запуск нового процесса. (Написал как-то наколеночный сет вотч-догов на bash'е и решил больше так не делать...)
> Внезапно, у ksh (из solaris 11) оказалось иное мнение о shell-совместимости, чем
> у bash'а.
> Напоровшись на этот прискорбный факт (что-то с циклами afair), перестал ограничивать себя
> "#!/bin/sh" - 1x большинство shell-скриптов проекто-зависимы.
> Однако, использовать раскормленный bash (да хотя бы и sh|ash) для
> cgi etc.?Ну, работает же! %) У самого на awk-е веб-сервер написан, и, да, даже не fork, а exec из-под xinetd (в другом варианте - из-под /usr/bin/socket). И ничего. Благо не лицокнижье.
> Да там же любой чих = запуск нового процесса. (Написал как-то наколеночный
> сет вотч-догов на bash'е и решил больше так не делать...)Да, баш для обработки строк - тормоз.:D
> Однако, использовать раскормленный bash (да хотя бы и sh|ash) для cgi etc.?http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in...
#!/bin/sh ващето. И башизмы мало кто любил. А меньше всего их любят те, у кого не только линукс.
В присутствии фанбоев неприлично упоминать о существовании чего-либо, кроме линукса.
А много ли тут людей помнят, какой был /bin/sh, скажем, в солярке аж до 11 версии? А писали под него?
ksh93
И таки да - писали, но потом всё накрылось.
Это с 11-ой. До 11-ой там совсем другое было, погуглите. Вкратце: там был доисторический pre-posix sh из 80-х, оставленный для bug-for-bug compatibility.POSIX-compatible там тоже был, но в /usr/xdg4
Вы знаете, я уже лет пятнадцать периодически наблюдаю истерику в массах "пишите на posix sh, а не на bash, так правильно". Однако, bash-only штуки здравствуют и процветают до сих пор.
процветают. это факт. прискорбный. потому что в общем-то говорят правильно. например некие скрипты внутреннего пользования или к примеру скрипты в обвязке дистроспецифичного софта - да заради бога. а вот когда например проект (например, kamailio) внутре содержит смесь sh/bash скриптов и немеряными башизмами - это не есть гуд.
Ну, раз прискорбный -- возьмите и перепишите как правильно. Оно же GPL.А то рассуждать в духе "они все козлы, ложить хотели на posix sh и используют bash, а это же _неправильно_" уж больно легко и неконструктивно. Повторюсь, я таких ораторов уже 15 лет наблюдаю, погоды они не делают.
> Повторюсь, я таких ораторов уже 15 лет наблюдаю, погоды они не делают.Хе-хе :) Сейчас начнут выносить линукс сервера _тысячами_, гонка идёт кто вперед good folks or bad one :)
Если черные шляпы гонку выиграют у многоих тут не то что "погода" испортится, им резьбу сорвут кой где :) А топом нарежут новую, но левую и на 22 :)))
>> Повторюсь, я таких ораторов уже 15 лет наблюдаю, погоды они не делают.
> Хе-хе :) Сейчас начнут выносить линукс сервера _тысячами_, гонка идёт кто вперед
> good folks or bad one :)насколько я понимаю, vunerable -- системы, где:
1. bash есть линк на /bin/sh. это не все линуксы. дебубунту пролетают, а это много.
2. используется именно bash (как интерактивный шелл или как обработчик для вызова). опять же, не обязательно все линуксы и не обязательно только линуксы.
=> это серьёзный баг, но не linux-specific.
> а вот когда например проект (например, kamailio)
> внутре содержит смесь sh/bash скриптов и немеряными башизмами - это не
> есть гуд.ну тут нечего удивительного - много народу прикладывает руку к продукту...
В свое время делал на заказ большую систему из скриптов (а я то предлагал perl, но...) и без bash её просто невозможно было бы написать чтоб удовлетворить требования заказчика. Потом, после меня, в нее вносили дополнения, где на простом sh, а где и на bash, собственно что можно ожидать от этого?
зы. Мой продукт НЕ kamailio! :)))
> # ln -s dash /bin/bashЕсть уверенность что в dash нет таких развеселых багов?
>> # ln -s dash /bin/bash
> Есть уверенность что в dash нет таких развеселых багов?Вероятность наличия в нем таких нежданчиков все же ниже на порядок, потому что это просто реализация POSIX shell, а не гибрид ежа с ужом, сделанный в попытке превратить интерактивную оболочку в полноценный мультипарадигменный ЯП.
>> Есть уверенность
>>?
> Вероятность наличия в нем таких нежданчиков все жеТо есть есть _не_уверенность. Оки-доки.
> То есть есть _не_уверенность. Оки-доки.А вам таки нужна _уверенность_? Тогда выключите компьютер, вынесите его на помойку и удалитесь в сибирские леса жить отшельником.
По крайней мере он значительно проще, так что и багов должно быть меньше.
> По крайней мере он значительно проще, так что и багов должно быть меньше.В общем, так оно и есть. К ShellShock он неуязвим by design.
>> # ln -s dash /bin/bash
> Есть уверенность что в dash нет таких развеселых багов?В процитированном сквозит уверенность в том, что /bin/dash есть...
Не, зачем? /bin/sh -> /bin/dash, а тем кто использует /bin/bash в скриптах, оторвать руки.
> Не, зачем? /bin/sh -> /bin/dash, а тем кто использует /bin/bash в скриптах,
> оторвать руки.На лоре писали что dash тоже уязвим.
> На лоре писали что dash тоже уязвим.
> На лореВесьма авторитетный источник. Особенно если учесть, что dash не умеет в функции в переменных.
>> На лоре писали что dash тоже уязвим.
>> На лоре
> Весьма авторитетный источник. Особенно если учесть, что dash не умеет в функции
> в переменных.Оно таки большая проблема? И позарез нужны ну просто каждому?
>> Весьма авторитетный источник. Особенно если учесть, что dash не умеет в функции
>> в переменных.
> Оно таки большая проблема? И позарез нужны ну просто каждому?Не видел, чтобы кто-то их использовал всерьез. Собственно, поэтому их отсутствие - это бонус, а не проблема.
apt-get update
apt-get upgrade
git clone https://github.com/hannob/bashcheck.gitbashcheck/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 bugssed -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
А знаете, что здесь самое интересное? То, что dash изначально был not vulnerable, и для него точно не было 0-day :)// Что касается CVE-2014-7187, то к группе shellshock эту уязвимость отнести нельзя, ввиду сложности ее удаленной эксплуатации.
Всё логично - если в компоненте продукта проявляется большинство багов, они и будут продолжать появляться в ней. В Firefox это всегда был js: https://www.st.cs.uni-saarland.de/softevo/vulnerabilities.php
> qmailДядюшка Берштейн cpeт кирпичами от такой подставы :).
Угу. По ссылке: нет bashа - нет проблемы. Там же (со слов автора) - дядюшка в курсе.
Какая то ошибка в скрипте проверки.
lol
проснулся - первым делом обнови баш
Кстати да, в генте сегодня прилетело уже 4-е обновление его со дня, когда обнаружили первую уязвимость.
> проснулся - первым делом обнови башs/обнови/удали/
> проснулся - первым делом обнови башДа, перечитывал как раз недавно. Хорошая сказка, и дядька был хороший.
Следующая новость: "В связи с последними событиями bash переименован в resheto."
Вот тебе и одобреная столманом лицензия.. не защитила..
http://www.fsf.org/news/free-software-foundation-statement-o...
а шо отвественности нету? а чем тогда бонус GPL перед MIT ?
> а шо отвественности нету?Хочешь ответственности? Райвоенкомат ждёт тебя! >/>>>
Упомянутый патч от 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
А другие скорлупки кто-нибудь проверять собирается?
возможно кто-то прямо сейчас и проверяет (или уже проверил и теперь занимается прокачкой своего ботнета)
ROSA тоже обновила bash
> ROSA тоже обновила bashВидите ли, интересней обратное -- можно сразу в отдельную новость списком оказавшихся неживыми.
Побежал проверять, а все дырки уже закрыты
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
Блин, а на debian 6 так и не вышло обновление, с 7-го вручную поставил.
Загугли, как прописать в sources.list squeeze-lts, будет обновляться. На опеннете, кстати, была новость про эту самую лтс-поддержку пакетов для скуеезе.
Хоть бы обходной путь то пофиксили. Уже 3 дня известна уязвимость. А криков про крутость опенсорса то было...
Обходной путь давно известен - отключить бинарным ключом. Но онанимусы видимо Выше таких вещей
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/bas...
2014-09-26 01:18 https://lists.debian.org/debian-security-announce/2014/msg00...
нужно срочно разработать новый,совершенный форк баша - librebash!
ты неправильно прочитал мысли Поттеринга, жди bashd
вся та затея sd - попытка заменить баш. Читая между строк, неудивительно, что букет иксплойтов вероятно будет (по унаследованным соображениям). Стоит копнуть поглубже...Благодаря "сквозной" архитектуре sd - будет более утончённый контроль за хостами...
> вся та затея sd - попытка заменить баш.И все когда-либо написанные на нём. И на любых прочих шелах. И ещё немного (dhcp), и потом ещё... ///Но _питон_ РХ одбряет -- видимо, _аудитория_ импонирует.
+++Обогнать GNU Emacs(*)! ---И сдохнуть. (*)В SLOC-ах Си-кода.
> Благодаря "сквозной" архитектуре sd - будет более утончённый контроль за хостами...
"за ботнетами", вы хотели? %)
Народу нужен новый баш, соответсвующий настоящим реалиям и без проблем с сабшеллами. Конечно это усложнение, но все может быть.Вообще да - в общем питончик вполне. Но почему-то гентушники в портаже ебилды сделали на баше, хотя у них была возможность взять питон...
В общем bash++ или bash-ng или bash2.0 или cash ;) - короче такой, чтобы можно было не городить сабшеллы, остальное сообразуется. Разумеется это должно быть без усложнений и ломки совместимости.
> Но почему-то гентушники в портаже ебилды сделали на баше, хотя у них была возможность взять питон...А вы попробуйте переписать какой-нибудь баш-скрипт на питоне.
Слишком много неалфавитных символов.
Xasd, перелогинься.
> вся та затея sd - попытка заменить баш. Читая между строк, неудивительно,
> что букет иксплойтов вероятно будет (по унаследованным соображениям). Стоит копнуть поглубже...В пору конкуренции с upstart, аудиторы, нанятые канониклом, пытались найти дырки в systemd. Безуспешно.
найдут еще...плохо искали...
> найдут еще...
> плохо искали...Просто они с РХ больше взяли%))))
> плохо искали...Хорошо искали. На карты была поставлена честь корпорации и лично Марка Ш.
>На карты была поставлена честь корпорации и лично Марка Ш.Ну, за дырки кто-то другой заплатил больше. И?
Вряд ли коммерческая компания, у которой все доходы и расходы строго по ведомости, будет платить больше, чем оскорбленный олигарх.
Лошары!$ 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
А в чём ты набрал команду "zcat /proc/config.gz | grep SCRIPT". и как у тебя система с \бин\ш, указывающим на \дев\нулл, вообще работает? всякие скрипты инициализационные как работают? CONFIG_BINFMT_SCRIPT=нет - это полезная штука для всяких встраиваемых систем, но с обычным линукс десктоп несовместимая
> А в чём ты набрал команду "zcat /proc/config.gz | grep SCRIPT"Очевидно, в юзерском шелле, который прописан в passwd. Hint: кроме баша, есть и другие, более удобные и фичастые.
> как у тебя система с \бин\ш, указывающим на \дев\нулл, вообще работает?
Палитесь вы с обратными слешами :)
> всякие скрипты инициализационные как работают?
В современных линукс-системах можно обойтись и без скриптов в ините.
> CONFIG_BINFMT_SCRIPT=нет - это полезная
> штука для всяких встраиваемых систем, но с обычным линукс десктоп несовместимаяПочему?
dash тоже уязвим.
> dash тоже уязвим.Во-первых, при чем тут dash? "Более удобные и фичастые" - это не про него, явно.
Во-вторых, нет, не уязвим.
>> dash тоже уязвим.
> Во-первых, при чем тут dash? "Более удобные и фичастые" - это не
> про него, явно.
> Во-вторых, нет, не уязвим.ОнониМ, ну, покажите же, ваши прелести (cat /etc/shells ;)
> В современных линукс-системах можно обойтись и без скриптов в ините.Нельзя.
SystemdOS - не линукс.
> Нельзя.
> SystemdOS - не линукс.systemd/Linux, нравится вам это или нет, по факту сейчас является стандартом линукса.
С тапка пишешь?
Апокалипсис грядет!!! Покайтесь!!! Все быстро переползаем на оффтоп )))
PS хорошо что есть фря, а на фре есть sh ))
А томкат сервер как? тоже уязвим?
В этом весь GNU'тый софт.
В проприетарном уязвимости признавать не выгодно - продажи падают
> В проприетарном уязвимости признавать не выгодно - продажи падаютДа, там вас просто имеют за ваши деньги, и те кто продал и те кто хакнул ))
ПыСы и никакой паники )))
плохая OpenSUSE, даже уязвимости в ней не работают(((((((
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
В Debian wheezy выполнил:
apt-get install zsh
chsh -s /bin/zsh username
...
mv /bin/bash /bin/bak.bash
reboot
Все работает без багов.
Не?
Угу, а теперь погрепай на наличие вхождений '#!/bin/bash' в /usr/{bin|sbin} хотя бы :)
Совершенно верно. Только можно и так:
mv /bin/bash bak.bash; ln -s /bin/zsh /bin/bash
Поскольку zsh практичвески все хавает, что на bash.
Вот только от CVE-2014-7186 и CVE-2014-7187 к сожалению не спасает. :(
А так все скрипты запускаются.
Я в дебиане просто делал 'apt-get update' и 'apt-get dist-upgrade' и все что есть новое у wheezy, включая баш, он установил и все заработало :) (это на нашем веб-сервере).
> Я в дебиане просто делал 'apt-get update' и 'apt-get dist-upgrade' и все
> что есть новое у wheezy, включая баш, он установил и все
> заработало :) (это на нашем веб-сервере).Таких обновлений в дебиане было уже минимум три за пару дней. И вот-вот выйдут новые. Так что готовьтесь обновить ещё несколько раз :)
Точно. Только что выполнил обновление сервера на дебиане через 'dist-upgrade'Теперь уже "Not vulnerable to CVE-2014-7169 (taviso bug)"
/usr/bin/zsh
Арчик кросавчег: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
Это не баг. Это фича. Так было задумано с самого начала.
> Михаил Залевский (Michal Zalewski), известный польскийА почему не Михаль?
Или Ми́хал?
https://pl.wikipedia.org/wiki/Micha%C5%82_ZalewskiMichał Zalewski
Ми́хау? :(
https://upload.wikimedia.org/wikipedia/commons/0/0c/Pl-Micha...
Понеслась звезда по кочкам.
Сейчас начнут копаться в этом баше и еще с десяток подобных сюрпризов нароют