Выявлены (https://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_...) методы (CVE-2014-7169) обхода патча, представленного вчера для устранения критической уязвимости в Bash. Для решения проблемы подготовлен новый патч (http://www.openwall.com/lists/oss-security/2014/09/25/10). В дистрибутивах проблема пока остаётся неисправленной.Для проверки на наличие обходного пути эксплуатации уязвимости можно (https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c24) использовать (http://seclists.org/oss-sec/2014/q3/685) команду (успешно срабатывает после установки вчерашнего обновления bash в Ubuntu и Debian):
<font color="#461b7e">
env X='() { (a)=>\' sh -c "echo date"; cat echo
</font>Кроме того, уже проведены (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in...) попытки массового сканирования серверов на предмет наличия уязвимости в Bash. Первый же эксперимент выявил около 3 тысяч хостов, подверженных уязвимости в Bash при запросе корневой страницы по IP, без заполнения заголовка Host (при полноценном сканировании с указанием корректных имён домена таких сайтов может оказаться в 50 раз больше). Организация целевых атак на конкретные CGI-скрипты, например, на /cgi-sys/defaultwebpage.cgi из CPanel позволяет как минимум её в 10 раз расширить область действия атаки. Так как уязвимость очень проста в эксплуатации не исключается появление в ближайшее время червей, нацеленных на поражение конкретных проблемных CGI-скриптов.
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c24
Новость: http://www.opennet.me/opennews/art.shtml?num=40670
КСЖ. Все переходим на zsh?
на dash
+1
*
Переход вашего конкретного шелла ничего не даст - в нем такую уязвимость все равно не получится осмысленно использовать. Настоящая проблема в shell'ах, которые неявно вызывают различные системные сервисы - и в которые есть риск подсунуть выполнение произвольных команд - а от замены шелла конкретного пользователя там ничего не изменится.Тут есть обзор с примерами, как эта уязвимость может эксплуатироваться через сервисы: https://securityblog.redhat.com/2014/09/24/bash-specially-cr.../
Реальная проблема - кластерфак с экранированием и специальной интерпретацией всего чего можно. Это касается шелла, терминалов и прочего. Да, если вы копипастите совет из интернета - парочка неочевидных символов может заставить вашу терминалку сделать вовсе не то о чем вы подумали и вас постигнет волшебный хренакс.
Только в этом случае опять же не имеет значения, какой у вас шелл. Будь у вас хоть супер-секьюрный dash, env X='() { (a)=>\' bash -c "echo date"; cat echo сработает, т.к. ломает свежезапущенный bash.
> Только в этом случае опять же не имеет значения, какой у вас шелл.В случае hijack ввода через терминал - да, тип шелла пофигу. Не пофигу тип терминала. Вообще терминалы тоже некисло бы переделать с ноля и по людски. А не "на черно-зеленых ископаемых это было так, а потом все привыкли".
шшшшш тихо!
а то поцтеринг услышит
> а то поцтеринг услышитБлин, надо ему написать, доджен же кто-то привести этот пи..ц в порядок. А ему уже привычно тумаки получать за такую работенку :)
>> а то поцтеринг услышит
> Блин, надо ему написать, доджен же кто-то привести этот пи..ц в порядок.
> А ему уже привычно тумаки получать за такую работенку :)Мне кажется, не его специализация: ему демоны/подсистемы нравится писать (avahi, pulseaudio, systemd), а не программы для конечного пользователя или инструменты.
> шшшшш тихо!
> а то поцтеринг услышитон спит
Ну есть, например, Terminology: http://enlightenment.org/p.php?p=about/terminology&l=en
> Ну есть, например, TerminologyВ нем выпилили совместимость с древними терминалами, escape кодами и прочей мутью, позволяющей уйму внеплановой активности если за вводом недоглядеть?
> Все переходим на zsh?Угу. И сразу ждём поток CVE для Zsh :)
> КСЖ. Все переходим на zsh?Судя по монструозности zsh, ждать подобной уязвимости в его случае придётся ещё меньше. Тогда уже KSH, а лучше - dash или что-то столь же минималистичное.
Переходим на ksh93 ))))))))))))))))))
csh ftw? :)
> csh ftw? :)Вот вы все скрипты и переписывайте. Вместе с POSIX. :-\
> Вот вы все скрипты и переписывайте. Вместе с POSIX. :-\Да, скрипты это круто. Особенно когда вам ремотный DHCP сервер команд на выполнение подкинет, как на https://www.trustedsec.com/september-2014/shellshock-dhcp-rc.../
Нормальный такой метод поимения: ничего не надо - только на DHCP запрос ответить и получить шелл на системе. Как правило - рутовый.
> env X='() { (a)=>\' sh -c "echo date"; cat echoА что должно получиться?
Дату вывести.
env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: Нет такого файла или каталогакубунта с "вчерашним обновлением" :)
У вас, видимо, sh - это dash, а не bash.Не вводите людей в заблуждение.
> кубунта с "вчерашним обновлением" :)Потому что надо было так: env X='() { (a)=>\' bash -c "echo date"; cat echo
Работает.
$ 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 06:59:29 UTC 2014так и задумано?
строка "Thu Sep 25 06:59:29 UTC 2014" находится в файле ./echo, появившемся в результате действия команды.
поэтому если выполнить эту команду в каталоге, в котором находится команда echo, от имени суперюзера - echo перестанет быть программой.
> строка "Thu Sep 25 06:59:29 UTC 2014" находится в файле ./echo, появившемся
> в результате действия команды.
> поэтому если выполнить эту команду в каталоге, в котором находится команда echo,
> от имени суперюзера - echo перестанет быть программой.
> в результате действия командыДальше можно было и не продолжать. Зачем перезаписывать какое-то там echo, если мы можем выполнять любые команды?
> Дальше можно было и не продолжать. Зачем перезаписывать какое-то там echo,
> если мы можем выполнять любые команды?Очевидно, это был терпеливый пример. Более доходчивый по Бармину всё же стёр, хоть некоторые будут правы в том, что это негуманно по отношению к кандидатам на цифровой эквивалент премии Дарвина.
типа такой? env X='() { (a)=>\' bash -c "test_ echo rm -rf ~/*"; . test_
Kubuntu 14.04, после патча не работает:> env X='() { (a)=>\' sh -c "echo date"; cat echo
> date
> cat: echo: No such file or directory
> Kubuntu 14.04, после патча не работает:
>> env X='() { (a)=>\' sh -c "echo date"; cat echo
>> date
>> cat: echo: No such file or directoryИ до патча не должно, если sh = dash.
OpenSUSE 13.1: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 09:05:13 CEST 2014CentOS 7:
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 09:04:28 CEST 2014Получается, что не рпаботает.
>Для проверки на наличие обходного пути эксплуатации уязвимости можно использовать команду (успешно срабатывает после установки вчерашнего обновления bash в Ubuntu и Debian):Это точно не дистрибутиво специфичный баг?
Это обходной путь, срабатывает, только если _уже_ установлен патч.
На обеих машинах патч установлен.
> На обеих машинах патч установлен.и тебя не смущает тот факт, что оно выводит дату?
> На обеих машинах патч установлен.Вообще-то, пример сработал. Заметь, команда с датой - выполнилась. Что самое прикольное, фанату редхата это объясняют скрипткидисы от убунту и бсд :).
Работает, раз файл echo создаётся.
> Работает, раз файл echo создаётся.Ты прав
Ubuntu 12.04
~$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: Нет такого файла или каталогаПосле вчерашнего патча, новый патч не ставил
Для Ubuntu/Debian работает так:
env X='() { (a)=>\' bash -c "echo date"; cat echoТам sh смотрит на dash, в котором уязвимости нет.
> Там sh смотрит на dash, в котором уязвимости нет.Попробовал явно запустить /bin/bash, результат аналогичный.
> Попробовал явно запустить /bin/bash, результат аналогичный.А, тормознул, надо bash еще и в самой конструкции. Вон та инструкция для бздунов работает и на убунтах. Pwnage такой pwnage...
FreeBSDenv X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory
> FreeBSDА причём тут FreeBSD? Или намёк на то, что в их ports уже давно используется patch для bash, который исправляет эту проблему?
>> FreeBSD
> А причём тут FreeBSD? Или намёк на то, что в их ports
> уже давно используется patch для bash, который исправляет эту проблему?не поверишь, но вчерашний патч для ЭТОГО там есть, в портах, да.
>>> FreeBSD
>> А причём тут FreeBSD? Или намёк на то, что в их ports
>> уже давно используется patch для bash, который исправляет эту проблему?
> не поверишь, но вчерашний патч для ЭТОГО там есть, в портах, да.Он там появился до данной новости или после?
>>>> FreeBSD
>>> А причём тут FreeBSD? Или намёк на то, что в их ports
>>> уже давно используется patch для bash, который исправляет эту проблему?
>> не поверишь, но вчерашний патч для ЭТОГО там есть, в портах, да.
> Он там появился до данной новости или после?r369185 2014-09-24 20:05:47 +0300
Ну так бы и написали, что в портах FreeBSD проблема была устранена r369185 2014-09-24 20:05:47 +0300..IMO, было совершенно непонятно, что вы хотели сказать в своём первом комментарии.
> Ну так бы и написали, что в портах FreeBSD проблема была устранена
> r369185 2014-09-24 20:05:47 +0300..
> IMO, было совершенно непонятно, что вы хотели сказать в своём первом комментарии.прошу прощения, как-то не привычно, когда на данном ресурсе спрашивают просто потому что интересно, а не чтобы подколоть:)
> А причём тут FreeBSD? Или намёк на то, что в их ports
> уже давно используется patch для bash, который исправляет эту проблему?Это намек на то, что фрибсдшники не понимают разницы между bash и sh.
А как еще объяснить то, что на баш-специфичную уязвимость они тестируют именно sh?
а убунтохомяки всё осваивают телепатию. и что характерно - всё неудачно.
> а убунтохомяки всё осваивают телепатию. и что характерно - всё неудачно.Еще один образчик годного батхерта. Хомяки vs снобы: 2:0 :)
Для фряхи и всем тем, у кого /bin/sh это не баш, нужно заменить в приведенной команде sh на bash:env X='() { (a)=>\' bash -c "echo date"; cat echo
$ uname -rs
FreeBSD 10.0-RELEASE-p9$ echo $BASH_VERSION
4.3.25(1)-release$ bash --version
GNU bash, version 4.3.25(1)-release (i386-portbld-freebsd10.0)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.$ env X='() { (a)=>\' bash -c "echo date"; cat echo
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
date
cat: echo: No such file or directory
А я уже давно сделал так:
# emerge dash eselect-sh
# eselect sh set dash
[ebuild U ] app-shells/bash-4.2_p48-r1 [4.2_p48]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'
date
cat: echo: Нет такого файла или каталога:P
Думаю, надо написать новый шелл для системдос, а баш выкинуть.
> Думаю, надо написать новый шелл для системдос, а баш выкинуть.ЛенартОСу не нужен шелл. Можно выкидывать сразу! ><//////>
> Думаю, надо написать новый шелл для системдос, а баш выкинуть.В системдос не должно быть шелла, ибо лишний вектор уязвимости, и Леннарт не одобряет.
>> Думаю, надо написать новый шелл для системдос, а баш выкинуть.
> В системдос не должно быть шелла, ибо лишний вектор уязвимости, и Леннарт
> не одобряет.Не, уязвимсость это новое. Основная архитектурная идея s-d ещё c самого начала была "любую проблему можно решить конфигом из 5 строчек(*1), поэтому bash^Wшелл не нужен".
(*1) формата VAR$n=$m, где n&m - правильно подобранные под задачу целые(*2).
(*2) разрядность не уточняется.
>>> Думаю, надо написать новый шелл для системдос, а баш выкинуть.
>> В системдос не должно быть шелла, ибо лишний вектор уязвимости, и Леннарт
>> не одобряет.
> Не, уязвимсость это новое. Основная архитектурная идея s-d ещё c самого начала
> была "любую проблему можно решить конфигом из 5 строчек(*1), поэтому bash^Wшелл
> не нужен".Ну, продолжай цепочку дальше! "Потому, что линуксойды относятся к разновидности хомо, именуемой No_Script и скрипты не умеют даже читать, не то, что писать". :))))))
>поэтому bash^Wшелл не нужен".
> Ну, продолжай цепочку дальше! "Потому, что линуксойды относятся к разновидности хомо, именуемой
> No_Script и скрипты не умеют даже читать, не то, что писать".
> :))))))Немедленно патчите броузер! У вас тэг сарказьм http:/openforum/vsluhforumID3/99256.html#29 в нём сломан -- уязвимость. //Ну или комбо "двойной сарказм" не удалось. Тренеруйтесь ещё!
test -d /run/systemd && echo "vulnerable"
> успешно срабатывает после установки вчерашнего обновления bash в Ubuntu и DebianКак бэ статистика опеннета говорит об обратном. Успешно он сработал на Сюсе и ЦентОс, а как раз на Убунтах, Генту и ФриБСД он не срабатывает.
>> успешно срабатывает после установки вчерашнего обновления bash в Ubuntu и Debian
> Как бэ статистика опеннета говорит об обратном. Успешно он сработал на Сюсе
> и ЦентОс, а как раз на Убунтах, Генту и ФриБСД он
> не срабатывает.В генту пофиксили сегодня только около 10 утра - выкатили апдейт сразу в стейбл. В дебе/убунте /bin/sh разве не симлинк на dash по дефолту, или это изменение они уже откатили? Я просто не в курсе. Во фре /bin/sh - это стопроцентно не баш, так что меняйте в приведенной в посте команде sh на bash.
>Во фре /bin/sh - это стопроцентно не баш, так что меняйте в приведенной в посте команде sh на bash.но у меня bash не установлен на FreeBSD.
т.е. для активации уязвимости мне необходимо сначала поставить bash из портов?--
вы бы тогда уточняли, что это только для тех, у кого установлен bash.
> Как бэ статистика опеннета говорит об обратном. Успешно он сработал на Сюсе
> и ЦентОс, а как раз на Убунтах, Генту и ФриБСД он
> не срабатывает.Статистика говорит о том, что на Убунту и ФриБСД сидят скрипт-киддисы, которые втупую запускают тесты, не вдумываясь в их смысл. И не в курсе, что sh - это далеко не всегда bash.
> Статистика говорит о том, что на Убунту и ФриБСД сидят скрипт-киддисы, которые
> втупую запускают тесты, не вдумываясь в их смысл. И не в
> курсе, что sh - это далеко не всегда bash.не надо проецировать свои проблемы на других.
> не надо проецировать свои проблемы на других.Диагностирован батхерт :)
От тебя большего и не ждали.
Даже если предположить, что все Убунтоиды, ФриБСДшники и Гентумены ничего не знают(вы сами в это реально верите?) то это значит, что баш они не используют/удалили/не ставили и ложили они на эту уязвимость.
в tcsh тоже срабатывает - не только в bash.
> в tcsh тожеНам ждать ещё и Hовостей "И я тоже!" от череды само-раскапывающихся xxxsh-стюардесс? Оживляж!
Молодцы, обошли. А фиксить-то будут?
Наверное нет.
Где фикс??? А-а-а-а, мы все умрём!!!
> Где фикс??? А-а-а-а, мы все умрём!!!Вы так говорите, как будто это что-то плохое
сила и мощь опенсорца: дыра есть, а исправлять её некому
Fix CVE-2014-3659. The original fix in 25 was not enough.Obtained from: http://seclists.org/oss-sec/2014/q3/690 (bash developer)
Security: CVE-2014-3659
> сила и мощь опенсорца: дыра есть, а исправлять её некомуК моменту вашего комментария, проблема была исправлена на большинстве наших серверов.
в ночи разродились, к моменту написания моего комментария и несколько часов после него, нихрена не было. Вместе с тем, у бздунов и гентушников весь день всё было ок, ибо патч им подогнали раньше.
> в ночи разродились, к моменту написания моего комментария и несколько часов после
> него, нихрена не было. Вместе с тем, у бздунов и гентушников
> весь день всё было ок, ибо патч им подогнали раньше.Ну, мы пытаемся делать защиту многослойной. Если кто-то что-то взломает, ему понадобится взламывать ещё много чего, чтобы хоть что-то полезное для себя получить. И сегодня будем заниматься анализом логов. К тому же данная уязвимость представляет хоть какую-то опасность для очень малого количества наших сервисов… В общем, я не вижу на что жаловаться.
Но если ближе к сути:
> сила и мощь опенсорца: дыра есть, а исправлять её некому
Патчи появились достаточно быстро. А если есть какие-то реально уязвимые сервисы, то их можно просто опустить на несколько часов (пока патч не появится)… ну или принять какие-то другие меры (в зависимости от обстоятельств), например заменить bash на что-нибудь, сделать обёртку для bash с проверкой символов "(){}" в переменных окружения, или добавить правило в iptables, или ещё что.
Жалуюсь на немощный редхет, у которого есть исходники, работники и что там ещё, а пакетов не было. По воводу многослойности: ко мне ночью приходил один такой искатель башей, его нжинкс редиректом прогнал.
> Жалуюсь на немощный редхет, у которого есть исходники, работники и что там
> ещё, а пакетов не было. По воводу многослойности: ко мне ночью
> приходил один такой искатель башей, его нжинкс редиректом прогнал.Лично я ассоциирую Red Hat с Microsoft (только уже в мире СПО). Не думаю что стоит ориентироваться именно на него, говоря при этом про всё СПО.
> Лично я ассоциирую Red Hat с Microsoft (только уже в мире СПО).Ну да, такие фаготы - 25% работы над ядром воротят. А в благодарность их с MS сравнивают. Довольно свинский подход.
>> Лично я ассоциирую Red Hat с Microsoft (только уже в мире СПО).
> Ну да, такие фаготы - 25% работы над ядром воротят. А в
> благодарность их с MS сравнивают. Довольно свинский подход.справедливый подход. Превратить гну линукс в системдос это такая же срань, как и превратить сперва домашний компьютер, а после и вообще все кипятильники на х86, в запускалки вантузов
>> Лично я ассоциирую Red Hat с Microsoft (только уже в мире СПО).
> Ну да, такие фаготы - 25% работы над ядром воротят. А в
> благодарность их с MS сравнивают. Довольно свинский подход.25%? Откуда у вас такая информация? Больше всего вносит Intel, и его доля и то лишь 10%. Но а так, даже Microsoft был некоторое время в top-листе contributor-ов ядра Linux, хотя их основная деятельность направлена не на СПО... А представьте, если бы они специализировались именно на СПО, то что было бы?
В общем, IMHO, это не показатель. А вот то, какие стандарты и подходы они используют и пытаются проталкивать -- это уже более показательно. Облачности, systemd, GFS2 (который хрен где заведётся, кроме как на их ядре) и т.п.
На большинстве ваших, а на большинстве остальных? И всем дружно костыли городить в iptables? В дистрах заплатка не появилась. Вчерашняя не в счет, т к неполноценная.
> В дистрах заплатка не появилась. Вчерашняя не в счет,
> т к неполноценная.В каких «дистрах» заплатка не появилась?
>> В дистрах заплатка не появилась. Вчерашняя не в счет,
>> т к неполноценная.
> В каких «дистрах» заплатка не появилась?убунта, арч, альт, другие не юзаю сейчас.
>>> В дистрах заплатка не появилась. Вчерашняя не в счет,
>>> т к неполноценная.
>> В каких «дистрах» заплатка не появилась?
> убунтаНе пользую, не знаю…
> , арч
Один мой коллега сказал, что там фактически сразу появилось исправление.
> , альт
С ALT-ом у меня проблема в том, что он сертифицированный ФСТЭК, и я бы не хотел обсуждать принятые меры на публичном ресурсе. Но проблема чисто технически решилась быстро, напрочь и очень легко.
> , другие не юзаю сейчас.
У нас на Gentoo и на Debian не было никаких проблем со скоростью появления исправленного bash.
> Не пользую, не знаю…Приехал "дважды пофикшеный". Фикс на фикс - это круто!
В убунтах давно появилась, я имею ввиду вторую.
В убунте сабжевая команда не работает, в арче ли альте работает (после обновлений)
Вру. там просто sh ссылается на dash. Уязвимость есть.
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: Нет такого файла или каталога
$ bash --version
GNU bash, version 3.2.52(1)-release (x86_64-alt-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
http://git.altlinux.org/gears/b/bash.git
Тухлость тоже вариант, это да.
> Тухлость тоже вариант, это да.Готов поспорить, CP/M неуязвима для этого бага :).
> Тухлость тоже вариант, это да.(ехидно) Расскажи это ВВС США после войны в Югославии.
"Продается два слегка побитых F-117. Самовывоз из Югославии"
Слегка тухлые радары 60х их видели как стеклянных. Ну и, соответственно, палить в них можно было.
Видаль сосун, как резво 117е после войны вывели из обращения? :D
env X='() { (a)=>\' bash -c "echo date"; cat echo
В альте баш - дефолт, хотя у Шигорина может быть что угодно.
> В альте баш - дефолт, хотя у Шигорина может быть что угодно.zsh, разумеется. :)
Однако же
$env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory
А вот и PoC [1].[1] https://www.trustedsec.com/september-2014/shellshock-dhcp-rc.../
Ну хоть Поттеринг нам написал netwrokd, который неуязвим(для конкретно этой ошибки)
> А вот и PoC [1].
> [1] https://www.trustedsec.com/september-2014/shellshock-dhcp-rc.../на скриншотике слака уязвилась через dhcpcd.
есличо в слаке апдейтики приехали уже:
http://www.slackware.com/security/viewer.php?l=slackware-sec...
http://www.slackware.com/security/viewer.php?l=slackware-sec...
REPL - зло.
патчи к башу ваять - все равно что воду ситом вычерпывать.