Компания
1 055,37
рейтинг
29 сентября 2014 в 09:33

Разработка → Всё, что вы хотели знать об уязвимости Shellshock (но боялись спросить) перевод

Помните Heartbleed? Shellshock можно отнести к той же «весовой категории», с таким же стильным названием, хоть и без классного логотипа (кому-то из департамента маркетинга этой уязвимости надо бы этим заняться). Но у Shellshock есть потенциал стать не менее важной птицей, чем Heartbleed. И сейчас я хотел бы собрать воедино всю необходимую информацию, которая поможет всем желающим справиться с ситуацией и избежать возможных проблем из-за неочевидной, на первый взгляд, угрозы.

Для начала позвольте поделиться с вами некоторой информацией из блога Роберта Грэма, который провёл превосходный анализ уязвимости. Рассмотрим представленный ниже HTTP-запрос:

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74

Если его применить к диапазону уязвимых IP, то получим такой результат:



Проще говоря, Роберт заставил кучу удалённых машин пинговать его, просто отправив в сеть специально сформированный запрос. Беспокойство вызывает тот факт, что он заставил эти машины выполнить произвольную команду (в данном случае безобидный ping), что открывает широчайшие возможности.

Что такое Bash и зачем он нам нужен?

Можете пропустить это раздел, если вы уже в теме. Но если вы не знакомы с Bash, то рекомендую ознакомиться с информацией ниже для понимания общей картины. Bash — это командная оболочка (интерпретатор), широко используемая на Linux и Unix-системах, обычно с подключением через SSH или Telnet. Bash также может работать как парсер для CGI-скриптов на веб-сервере, например, на Apache. Свою историю Bash ведёт с 1980-х, где он развился из более ранних реализаций командной оболочки (название происходит от Bourne shell) и невероятно популярен. Конечно, есть и другие интерпретаторы, но Bash идёт по умолчанию в Linux и Mac OS X, которые, как вы понимаете, очень широко распространены. Этот интерпретатор даже признан «одной из наиболее распространённых утилит в Linux-системах». Именно распространённость Bash является главной причиной того, почему Shellshock столь опасен.

Этот график даёт наглядное представление о вездесущности Bash:



Половина интернета работает на Apache (обычно установленный под Linux), и это реально очень, очень много. В той же статье сообщается, что мы уже перешли рубеж в 1 млрд действующих веб-сайтов, а поскольку многие из них расположены на массовых хостингах, то мы имеем дело с огромным количеством установленных копий Bash. И помимо веб-серверов не забудьте ещё и о множестве других серверов и устройств под управлением Linux. Но вернемся к этому позже.

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

В чём суть уязвимости?

Степень серьёзности ситуации можно оценить по следующей цитате из базы данных уязвимостей NIST:

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Уязвимости присвоен уровень «10 из 10», то есть хуже некуда. Добавьте к этому лёгкость осуществления атаки (Access Complexity низкий) и, что ещё важнее, отсутствие необходимости аутентификации для использования Bash с помощью CGI-скриптов. Давайте разберёмся в сути самого бага.

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

http-header = Cookie:() { :; }; ping -c 3 209.126.230.74

Определение функции — это () { :; };, а команда интерпретатора — ping и её параметры. При обработке этой строки интерпретатором Bash, может быть выполнена любая команда. В контексте веба, это можно сделать через такой механизм, как CGI-скрипт и необязательно через заголовок запроса. Больше информации можно найти на страничке seclists.org, еще там установлено, что путь и строка запроса также могут быть потенциальным вектором атаки.

Конечно, ситуацию можно смягчить просто отключив функционирование CGI. Но во многих случаях это окажет слишком серьёзное влияние на ваш веб-сайт и, как минимум, потребует активного тестирования, чтобы удостовериться в его работоспособности.

Приведённый выше HTTP-запрос прост и эффективен, являясь лишь одним из многих возможных использований этого протокола. Если принять во внимание Telnet и SSH, и, очевидно, даже, DHCP, то масштаб проблемы вырастает многократно, несмотря на то, что мы говорим лишь об атаках на веб-серверы. Пока что опасность имеется только после аутентификации в SSH, но в дальнейшем мы обнаружим и другие векторы атаки.

Необходимо помнить, что возможности злоумышленников простираются далеко за пределы пингования конкретных адресов, как в примере Роберта, это лишь небольшой пример самой возможности управления удалёнными машинами. Сейчас вопрос стоит так: какой вред способны нанести злоумышленники, выполняя различные команды в интерпретаторах удалённых машин?

Каковы потенциальные последствия?

Получение доступа к интерпретатору всегда было большой победой для атакующего, потому что это равнозначно получению контроля над сервером (с соотвествующими правами). Доступ ко внутренним данным, перенастройка окружения, распространение зловредов и так далее. Возможности почти безграничны и автоматизируемы. Есть уже очень много примеров эксплойтов, которые могут быть легко применены против большого количества машин.

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

То же самое относится и к возможности записи файлов на удалённую машину. Это один из самых лёгких способов замены страниц чужом веб-сайте, не говоря уже о распространении вредоносного ПО. Или как вам вот это?



Когда речь заходит о червях, то подразумевается зловредное ПО, которое создаёт собственные копии на целевой системе. В качестве примера очень эффективного червя можно привести XSS-червя Samy, который инфицировал миллионы веб-страниц менее чем за один день.

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

Какие версии Bash подвержены уязвимости?

Все версии за последние почти 25 лет, включая 4.3. Сравните с Heartbleed, опасности которого были подвержены версии OpenSSL за последние два года. Да, люди обновляют версии, но это не делается планомерно, и как ни крути, Shellshock угрожает гораздо большему количеству машин, чем Heartbleed.

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

Когда была обнаружена уязвимость?

Первое найденное мной упоминание было в очень короткой заметке на seclists.org, опубликованной в среду около 14-00 по Гринвичу. Более подробная информация была выложена на том же ресурсе час спустя. Так что это очень «свежая» новость, и пока слишком рано говорить о массовом появлении эксплойтов в «дикой природе». Но это может произойти очень скоро, вероятность увеличивается с каждым часом.

Как упоминалось выше, уязвимость существует во всех версиях Bash, созданных за последние 25 лет. Так что, теоретически, всё это время знающие люди могли её использовать.

Наши девайсы под угрозой?

Вопрос интересный, ведь существует множество устройств, потенциально использующих Bash. Я имею в виду «интернет вещей» (IoT), когда всё более широкое распространение получает присваивание IP-адреса каждой мелочи, от вилки до дверного замка и лампочки. Многие «интернет-вещи» используют встроенные версии Linux с Bash. Те же самые девайсы уже продемонстрировали серьёзные прорехи в безопасности, например, с лампочек LIFX можно получать идентификационные данные по Wi-Fi. Так что уже и без уязвимостей вроде Shellshock мы оказались в ситуации, когда, подключая к сети всевозможные устройства и предметы, мы получаем множество новых уязвимостей в тех сферах, которые ранее были абсолютно безопасны.

Это ставит перед нами множество новых задач. Например, кто-нибудь задумывается о том, чтобы регулярно ставить патчи на лампочки? Учитывая «долговечность» подобных устройств, вряд ли кто-то будет заниматься поддержкой встроенного ПО. Вспомните историю с камерами Trendnet, произошедшую пару лет назад. Несомненно, огромное их количество всё ещё остаётся подключёнными к сети, потому что с точки зрения обновления ПО их гораздо проще поставить и забыть. Есть Твиттер-аккаунт, целиком посвящённый публикации снимков с подобных камер, когда их владельцы даже не знают, что их снимают. Это большая проблема, ведь обновление ПО периферийных устройств зачастую затруднено, так что нас со временем будет окружать всё больше устройств и предметов со всевозможными уязвимостями.

Но интерпретатор Bash также уже присутствует во многих привычных устройствах, например, домашних роутерах. Когда вы в последний раз обновляли его прошивку? Конечно, если вы читаете этот текст, то, вероятно, вы из тех, кто регулярно занимается подобными вещами. Но обычные пользователи об этом даже не думают.

У нас всё работает на ПО от Microsoft, нам надо беспокоиться?

Короткий ответ — нет, длинный — да. Несмотря на то, что существуют версии Bash под Windows, для этой экосистемы данная утилита не является сколь-нибудь распространённой. Также неясно, имеют ли уязвимость Shellshock Windows-версии Bash.

Однако тот факт, что вы работаете в исключительно в Windows-среде не означает, что Bash отсутствует на машинах, обслуживающих отдельные задачи вашей сети. В качестве поясняющей картинки хочу привести иллюстрацию из поста Ника Крэйвера:



Как видите, трафик проходит от вашей Windows-среды через неWindows-устройства. Могут быть компоненты, имеющие привилегии над фаерволом, что можно будет натворить тогда с помощью Shellshock?

Я сисадмин, что я могу сделать?

Во-первых, очень легко определить, находитесь ли вы в зоне риска. Нужно просто выполнить эту команду в вашем интерпретаторе (позволил себе немного изменить изначальную команду — прим. pkruglov):

env X="() { :;} ; echo busted" bash -c "echo stuff"

Если выведется «busted», то уязвимость присутствует.

Конечно, нужно в первую очередь закрыть дыру. Патч существенно снизит риск выполнения чужого кода в конце Bash-функции. Для ряда Linux-дистрибутивов, например, Red Hat, уже появились инструкции, так что займитесь этим как можно скорее (на самом деле, уже для большинства дистрибутивов вышли патчи — прим. pkruglov).

Уже появились инструкции по обновлению систем обнаружения вторжений (IDS), и их немедленно надо взять на вооружение различным организациям, особенно тем, в которых нужно проводить длительные тестирования перед установкой патчей. Провайдер Qualys предложил свой способ определения атаки, наверняка и многие другие IDS-провайдеры работают над этой проблемой.

Более кардинальные способы включают в себя замену Bash на другой интерпретатор, или блокирование подверженной риску системы. Оба способа могут иметь далеко идущие последствия, их не стоит применять бездумно. Но именно это может стать главной особенностью Shellshock: быстрое принятие трудных решений, которые могут оказать серьёзное влияние на реальный бизнес, ради избегания потенциально куда более значительного ущерба.

Ещё один вопрос встаёт куда более острее: эксплуатировался ли Shellshock уже кем-то ранее? Это сложно определить, если не фиксировались векторы атаки. И часто этого не будет происходить, если атака будет проводиться через HTTP или POST-запрос. На вопрос «были ли мы атакованы через Shellshock» самым частым ответом будет такой: у нас нет доказательств, что мы закрыли эту уязвимость. Это оставляет владельцев веб-сайтов и прочих систем в неприятной неизвестности относительно того, были ли они скомпрометированы.

Я пользователь, что я могу сделать?

Зависит от конкретной ситуации. Если вы пользуетесь Mac OS X, то эта уязвимость будет легко (и, надеемся, быстро) закрыта с помощью стандартного механизма обновлений. Проверить, находитесь ли вы в зоне риска, можно легко с помощью теста:



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

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

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

Итог

Судя по всему, мы находимся только в самом начале нашего исследования глубин этой уязвимости. Конечно, проведено много параллелей с Heartbleed, и в чём-то нам это даже помогло. На примере Heartbleed мы знаем, что ситуация может ухудшиться очень быстро, а последствия мы будем разгребать ещё очень долгое время.

Но в данном случае всё может быть куда хуже, чем с Heartbleed. Если та уязвимость позволяла получить удалённый доступ к небольшому количеству данных в памяти заражённой машины, то Shellshock даёт возможность внедрить произвольный код, что потенциально гораздо опаснее. В этом плане я соглашусь с Робертом:



Полагаю, пройдет день-два, и мы поймем, что это были еще только цветочки.

UPD. В продолжение — обнаружены новые уязвимости в bash www.linux.org.ru/news/security/10892232
Универсальный скрипт для проверки на наличие уязвимостей github.com/hannob/bashcheck
Автор: @pkruglov Troy Hunt

Комментарии (93)

  • –1
    Я не совсем понял почему это уязвимость Bash а не http-серверов?
    Я преполагаю что заплатки должны делать именно Apache и NGINX а не ОС
    • +1
      В чем должна заключаться заплатка веб-сервера? Запретить системные вызовы?
      • +5
        Делать корректный escape для задаваемых переменных окржения. См. ниже.
    • +6
      Проблема именно в bash, так как обработка в вышеприведенном примере продолжается даже после символа «}»
      • +18
        Не совсем понятен один момент: почему и зачем bash обрабатывает http header как команды? Очень не хватает технических подробностей…
        • +10
          bash обрабатывает http header в случае если сам http запрос обрабатывается cgi скриптом.
          Так получается потому что различные параметры клиента передаются cgi скрипту через переменные окружения.
          Например при запросе /test.cgi заголовок User-Agent переданный браузером экспортируется веб-сервером в переменную окружения HTTP_USER_AGENT и производит выполнение скрипта test.cgi.
          Сам скрипт test.cgi может быть как Perl'овым скриптом так и какой-нибудь программой на C/C++ которая может потом по желанию получить эту переменную окружения.
          • –1
            заголовок User-Agent переданный браузером экспортируется веб-сервером в переменную окружения HTTP_USER_AGENT
            Разве не было бы логично обновить веб-сервер (и не только), чтобы он корректно эскейпил заголовки и прочее непосредственно при передаче в баш?

            Ведь проблема не в том, что заголовки какие-то недопустимые с точки зрения веб-сервера, и проблема не в том, что баш делает что-то, что не должен, а в том что при передаче из веб-сервера в баш что-то, что было просто строкой стало интерпретироваться как часть компанды. То есть сама проблема аналогична SQL Injection и подобным. А чинить баш от уязвимости — это как чинить MySQL от SQL Injection: такой же костыль и так же бесполезно. Ибо проблема на уровне интеграции, а не на уровне исполнителя.
            • 0
              Тоже пришла на ум аналогия с SQLi. Однако в случае с bash не слишком ли много сервисов и кода пришлось бы патчить? Кстати, обнаружены новые уязвимости в баше — www.linux.org.ru/news/security/10892232
            • +11
              По-моему это как раз уязвимость именно баша — посмотрите на репродьюсер: env X="() { :;}; echo busted" bash -c «echo stuff»

              Он начинает испольнять строковый литерал. Может это на самом деле нормальное поведение для баша, но обычно даже самые динамично-высоко-уровневые языки не исполняют строки если их не просить.
            • +6
              Разве не было бы логично обновить веб-сервер (и не только), чтобы он корректно эскейпил заголовки и прочее непосредственно при передаче в баш?

              Веб-сервер отрабатывает корректно. Это bash не проверяет свои входные данные на корректность. Если у вас есть программа с одним окном и одним editboxом, в который пользователь вводит делитель, и при вводе 0 программа выпадает с division by zero, проблема в вашем коде, а не коде графической оболочки, реализующей editbox.
              • –4
                что значит «баш не проверяет свои входные данные»? Баш это не вебсервер, это все таки шелл. И как не простой шелл он предоставляет некоторые расширенные функции. Такие как например эта, используемая в уязвимости. Да, баш позволяет описывать в переменных окружения также свои функции. Это малоизвестная но таки фича баша. А вот авторы вебсерверов этот момент упустили, но в этом нет вины баша.
                • +5
                  То что он позволяет описывать функции — это, может быть, и фича. Но то, что написанный после этих функций код автоматически исполняется — уж точно нет.

                  Как вы представляете себе фикс этой проблемы на сервере? С какой стати web-сервер должен знать что там bash делает с переданными ему переменными? По спецификации он должен засунуть данные в переменную окружения и вызвать CGI-обработчик. Пытаться понять что там этот CGI-обработчик с переменными сделает — не его задача.
                  • –1
                    А кто в cgi обработчик то шелл запихал?
                    • +1
                      Сама CGI может быть написана на шелле. А может быть написана на другом языке, который в процессе работы сам для чего-нибудь вызовет шелл.
                      • –4
                        Вот вам и ответ. Виноват то в конечном итоге не баш, а тот кто его использует не зная его функционала. Да функционал неожиданный, но это как не смотря в документацию на допустимые параметры функции потом ругаться что «функция дырявая»
                        • +6
                          AFAIK описанное в статье — это не функционал баша. По крайней мере я описания такой «фичи» в документации баша не припомню. Это обычный баг. Ну или не баг, а закладка, причём древняя.
                        • +5
                          Нет у Баша такой функциональности — выполнять код из переменных окружения, есть только импорт функций, а описанная проблема — баг.
                          • 0
                            Ну, описанная проблема срабатывает если атакующий контролирует значение переменной окружения. А если атакующий контролирует не только значение, но и имя — импорт функций ВНЕЗАПНО тоже позволит выполнить свой код, если известно какую программу запускает bash (можно подменить группу типичных команд pwd/ls/mkdir/uname/id/… чтобы повысить вероятность):
                            $ env BASH_FUNC_uname%%="() { echo busted; }" \
                                bash -c uname
                            busted
                            
                            • +1
                              В частности, таким способом можно обойти ограничение ForceCommand в ssh если в конфиге сервера используется AcceptEnv *.
          • 0
            Т.е. при ЛЮБОМ вызове cgi-скрипта переменные окружения выставляются через системный вызов bash'а что-ли?
            • +2
              Тут похоже тесты и примеры немного всех запутали.
              Более наглядно на мой взгляд вот так:
              [test@localhost ~]$ export x='() { :;}; echo vulnerable'
              [test@localhost ~]$ bash -c "echo this is a test"
              vulnerable
              this is a test
              [test@localhost ~]$ /bin/sh -c "echo this is a test"
              vulnerable
              this is a test
              

              Т, е. установка переменных может осуществляться через setenv() или еще каким образом. Но стандартный вызов cgi-скрипта производится при помощи exec(«my.cgi»), что обычно равно выполнению "/bin/sh -c my.cgi". А это в свою очередь приводит к выполнению функции которую мы задали в переменной окружения.
              Это показывает еще момент с тем что дверью для этой уязвимости является не только веб-сервер, а фактически все что устанавливает переменные окружения из пользовательского ввода перед вызовом exec(). Упоминались в частности DHCP клиенты (не стоит опрометчиво подключаться к левым WiFi сетям).
              • +1
                Поправка 1:
                /bin/sh -c выполняет вызов system().

                С exec несколько сложнее — он может выполнить шелл но при определенных условиях.
                If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.)


                Поправка 2:
                Конкретно в apache виноват не exec() сам по себе. В нем используются вызовы execve() и execv() с явным указанием запускать шелл.
                apr-1.5.1/threadproc/unix/proc.c:543
                if (attr->cmdtype == APR_SHELLCMD) {
                    execve(SHELL_PATH, (char * const *) newargs, (char * const *)env);
                }
                else {
                    execv(SHELL_PATH, (char * const *)newargs);
                }
                
                


    • +6
      Потому что веб-серверы это всего-лишь одна из возможных лазеек. Уязвимостью можно воспользоваться в контексте любой программы или демона у которого есть возможность записывать переменные окружения или выполнять системные комманды.
  • 0
    OpenSuSE (даже для 11 ветки) фикс уже вышел
    Ubuntu LTS — фикс вышел.

    Накатите апдейты, друзья
    • 0
      Мне кажется фиксы выпустили уже все дистрибутивы Linux и Unix. Нет?
      • +1
        Это да. Другой вопрос — как скоро эти фиксы будут установлены везде
    • +4
      Апдейты накатили, вопрос больше с роутерами и тд. на которых нету новой прошивки. Что делать и насколько опасно?
      Задумался о всяких NAS типа синолоджи, это ж доступ ко всей приватной информации можно получить?
      • 0
        Вот меня тоже мой роутер волнует, т.к. адрес от провайдера получает по DHCP, а значит скрипт выполняет от рута, а не от www-data, как веб-сервер. Надеюсь, что там бизибокс. Всё же баш — штука тяжёлая и грузить ей устройство со слабеньким процессором и крошечной памятью нелогично.

        А вообще-то очень хочется какой-нибудь Cubieboard с несколькими ethernet-портами.
      • +1
        на роутерах всеми правдами и неправдами закрывайте доступ к вебсерверу извне, и даже в локальной сети по возможности ограничивайте доступ только с надежных машин (хотя бы по ip).
      • +4
        gavrish, wholeman, rPman
        На роутерах Bash бывает чрезвычайно редко (я ни разу не видел). В статье преувеличено.
        См. habrahabr.ru/company/mailru/blog/238475/#comment_8013525
      • +2
        Можно получить у производителя. Например, список уязвимых устройств от Cisco не маленький.
      • +1
        Не буду говорить за всех, но у двух используемых Synology (DS213, DS713) качестве интерпретатора используется sh, а не bash, который идет симлинком на busybox
        Для проверки на всякий случай выполнил, и получил хороший выхлоп (заменил sh на bash):
        NTC-DISK> env X="() { :;} ; echo busted" sh -c "echo stuff"
        stuff
        NTC-DISK>

        Впервые за всё время, рад что у MikroTik используется их закрытая оболочка, а не bash.
        • 0
          DS3612xs Release Notes Version : 5.0-4493 Update 7 (2014/09/29) Fixed Issues Fixed a potential risk on Bash command shell (CVE-2014-6271 and CVE-2014-7169)
          Без комментариев, Обновляйтесь
  • +6
    > Но интерпретатор Bash также уже присутствует во многих привычных приборах, например, домашних роутерах.

    Там чаще присутствует BusyBox, который этому вроде бы не подвержен.
    • 0
      Есть более подробная информация о busybox? Хотелось бы пруф…
      • +2
        BusyBox использует ash shell. Ну и например www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability
      • +3
        Я бы даже сказал не «чаще», а «совершенно всегда». Я ни разу не видел bash в дешевых embedded-устройствах вообще (не только роутерах), так что как бы масштабы трагедии СИЛЬНО преувеличены. Если с HeartBleed мы могли дампить память совершенно незаметно без всяких аутентификаций, то тут, во-первых, нужно найти вектор атаки (прямой CGI на Bash встречается, я думаю, чуть реже, чем никогда), где выполняется bash в ходе каких-то действий, и, как правило, это требует прохождения аутентификации.
        • +1
          Нет, вы недооцениваете опасность.

          Представьте себе CGI скрипт на perl, который делает exec('date >> ../logs/myscriptcalls.log').
          Так вот 'date >> ../logs/myscriptcalls.log' будет выполнено с помощью /bin/sh, который в слишком большом количестве дистрибутивов является симлинком на /bin/bash. Подробнее.
          • +2
            Я не вижу противоречий с моим сообщением. На embedded-устройствах bash встречается очень редко, а CGI perl-скрипт, вероятнее всего, будет требовать аутентификации (если это панель администратора, или типа того) для выполнения system() где-то внутри скрипта.
            • +1
              А во внятных статьях и не утверждают, что уязвимы SOHO роутеры, говорится только о том, что уязвима куча серверов.

              Но и этого достаточно.
  • –6
    За рассказ о bash без упоминания GNU Столлман бы Вам, наверное, «испанский воротник» сделал из
    своего "нимба")
  • +7
    debian squeeze — фикса нет. Серверов именно на squeeze огромное количество (по разным соображениям не обновленных на wheezy). Но в июне появился дистрибутив squeeze lts, с поддержкой до 2016 года — настоятельно рекомендую коллегам обновить веб-сервера до него. Версии пакетов фактически те же, приходят только security fixes, в т.ч. и bash shellock fix.
    • 0
      Нельзя просто подключить к работающему squeeze какие-то репозитории?
  • 0
    В тексте упоминается sshd. Получается, любой человек может удаленно выполнить любой код с правами рута (sshd крутится под рутом)? Или нужно все-таки залогиниться под каким-либо пользователем?
    • +4
      sshd сменит пользователя перед запуском оболочки. Так что пользователь будет тот, с которым залогинились.
    • 0
      Нужно залогиниться.
      • +3
        Представьте себе, что у вас ssh доступ только чтобы делать git clone ssh://myuser@gitrepo.
        Т.е. залогиться вы можете, но там ForceCommand на какой-нибудь git демон.

        Внезапно вы можете не только клонировать репу, но запускать там любые команды через шелл!
        • +2
          Совершенно верно. Но залогиниться нужно.
  • 0
    OS X 10.9.5 уязвим. Apple нынче слоупоки. Это обновление вышло после обнаружения уязвимости.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      OS 10.10 (14A361p) та же беда, пришлось самому обновлять интерпретатор.
  • +53
    Когда я в 98-м году начинал изучать веб технологии с пхп, как настоящий школьник, все инструкции по установке веб-сервера начинались со слов «не используйте CGI, это небезопасный способ работать с вебом, так как они вызывают системные скрипты». После этого мы прошли долгий путь: mod_php, tomcat, fastcgi, и в 2014 году ВНЕЗАПНО оказалось что CGI небезопасно!..
    • 0
      Глупости. CGI скрипты не более (небез)опасны чем любые другие — если программист не допустил ошибку в скрипте, то он безопасен пока не обнаружена дыра в ОС, веб-сервере, или используемом языке программирования. Можно подумать, с 98-го года было найдено мало дыр в апаче или php. Баш очень широко используется и давно превратился в bloatware, так что обнаружение в нём серьёзных дыр и багов было неизбежно.
  • +2
    А что бы проверить без сборки masscan-а достаточно curl-запроса:
    curl -A "ShellShock-check (0.1)" -H "Host:() { :; }; ping -c 3 209.126.230.74" <Attackrd_host>
    Поправьте меня, если ошибаюсь.
    • +2
      Если без сборки, то лучше использовать универсальный скрипт для проверки, который я добавил в статье, тем более, что там новые баги обнаружились github.com/hannob/bashcheck
      • +2
        Этот универсальный скрипт позволяет проверить текущую систему. А речь о том, чтобы, например, быстро проверить раутер своего провайдера.
        • –1
          Я запустил его на ADSL-модеме D-Link DSL-2500U (прошивка родная) и роутере D-Link DIR-825 (прошивка заменена на OpenWrt Backfire 10.03.1 — прошивке где-то года три, наверное). И там и там нет bash, используется busybox, проверка проблем не выявила (я заменял в скрипте bash на sh).
  • +1
    CGI? Реальная уязвимость же только с его использованием. С FastCGI и mod_php/mod_perl никакого запуска оболочки для передачи параметров уже не происходит.
    Так CGI пора давно было хоронить. Нашёлся отличный повод.
    • 0
      А при использовании fcgiwrap?
    • +3
      Не только. Как уже отмечали ранее, уязвимости подвержены многие сервисы, в том числе sshd, Git, Subversion, клиенты DHCP (если они вызывают скрипты для настройки системы), CUPS и вообще любые приложения, которые запускают bash (или bash-скрипты) и могут устанавливать переменные окружения на основе пользовательских данных.
      • +2
        Помню была задача: получить рутовый баш, имея пользователя, которому разрешены некоторые административные команды через sudo. Среди прочего оказалось, что разрешена edquota, и задача легко решилась манипуляциями с переменной окружения EDITOR. Shellshock добавляет уйму возможностей при подобной конфигурации системы.
    • +1
      Если тот же perl или php хоть раз рождает дочерний процесс через баш, то проблема остаётся даже с mod_php/mod_perl. Весьма многие веб-приложения этим занимаются.
  • 0
    >Также неясно, имеют ли уязвимость Shellshock Windows-версии Bash.

    $ bash --version
    GNU bash, version 4.1.13(6)-release (i686-pc-cygwin)
    
    $ env X="() { :;} ; echo busted" bash -c "echo stuff"
    stuff
    


    С Cygwin все в порядке.
    • +4
      C:\Program Files (x86)\Git\bin>set X=() { :;} ; echo busted
      
      C:\Program Files (x86)\Git\bin>bash -c "echo test"
      busted
      test
      
      C:\Program Files (x86)\Git\bin>bash --version
      GNU bash, version 3.1.0(1)-release (i686-pc-msys)
      Copyright (C) 2005 Free Software Foundation, Inc.
      
      • 0
        Изнутри bash'а тоже работает:
        bash.EXE"-3.1$ export X="() { :;} ; echo busted"
        bash.EXE"-3.1$ ./bash -c "echo stuff"
        busted
        stuff

        Возможно, env функционирует не совсем так как надо? Но это абсолютно не влияет на уязвимость.
      • +2
        Cygwin все таки подвержен:

        image

        отсюда: twitter.com/ErrataRob/status/514987601737289728/photo/1
  • +2
    Не надо зацикливаться на веб-векторах, которые в современном мире не представляют массовой угрозы (речь конкретно о Shellshock). Есть и другие, более актуальные и опасные варианты эксплуатации уязвимости.
    • –1
      Вот из статьи не ясно как эта уязвимость может быть использована вне динозавроподобного CGI?)
      Вот мой сервер: t.syshub.ru на нём нет ничего интересного, и старый баш. Если кто запишет в /tmp/res номер своего кошелька (на яндексе или webmoney) и запрос, который создал файл скину на него денежку)

      Для проверки открыт apache (80) sshd (1122) webmin (10000).
  • +1
    bash --version
    GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

    ни одной уязвимости.
    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


    в версии 2009 года 4.1.2 тоже нет
    • +2
      Тогда я не понял, этому багу действительно 25 лет, или это таки недавно добавленная АНБ закладка?
      • 0
        Тоже интересно: кому таки реально стоит переживать? была проблема 2К, но её тоже пережили и не заметили, слышал лишь про пару случаев на древних тазиках.
    • 0
      GNU bash, version 3.1.17(0)-release (i386-portbld-freebsd6.2)
      Copyright (C) 2005 Free Software Foundation, Inc.
      Vulnerable to CVE-2014-6271 (original shellshock)
      Not vulnerable to CVE-2014-7169 (taviso bug)
      ./test.sh: line 20: 49172 Segmentation fault: 11  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)
      

      Увы, есть оная в более древних версиях
  • 0
    Правильно я понял, что если CGI-программы написаны, скажем, на С и не вызывают bash в процессе своего выполнения, то опасности нет?
    • –1
      Неправильно.
      bash будет вызван автоматически для запуска cgi написанного даже на C. тыц1 тыц2
      • +1
        По этим ссылкам написано, что шелл будет вызван, только если бинарник почему-то не распознается системой. И это будет /bin/sh, который не обязательно bash, например, в Debian и Ubuntu это dash.
        • 0
          apache вызывает шелл для запуска cgi самостоятельно. Случай с не распознанным файлом — относится к другим программам. Но да, в случае с apache это все равно будет "/bin/sh" и если /bin/sh = dash то вероятно угрозы нет.

          apr-1.5.1/include/arch/unix/apr_arch_threadproc.h:51
          #define SHELL_PATH "/bin/sh"
          


          В таком ключе мое сообщение выше стоит читать как:
          /bin/sh будет вызван автоматически для запуска cgi написанного даже на C.
          Вопрос чем является /bin/sh
  • +1
    Сказал «yum update» на CentOS, теперь скрипт https://github.com/hannob/bashcheck не показывает ни одной уязвимости.

    Спасибо за свéдения.
  • +3
    Извините, но ИМХО тема топика не раскрыта. Желтовато-с. Описано, как воспроизвести уязвимость, но по механизму ее работы остается как минимум три вопроса.

    1. Почему вообще bash пытается как-то интерпретировать содержимое переменной окружения? Это ведь обычная NUL-строка, передающаяся из родительского процесса в дочерний (в system или при должных аргументах exec).

    2. Идет нагон тумана на тему того, что Apache+CGI уязвимы сами по себе. Но ведь если я написал CGI-скрипт с hello world на Perl, положил его в /cgi-bin/ и открыл в браузере, с какой стати там вообще запустится bash? Он не запустится, потому что если бы Apache на каждый cgi-скрипт запускал перед ним bash, это были бы лишние тормоза. Таким образом, уязвимость проявится только в случае, если кто-то в cgi-скрипте вызовет system(), exec(), popen() и др. функции по запуску внешних процессов.

    3. Если внешний процесс запускается не «командной строкой с аргументами», а отдельным указанием исполняемого файла и отдельным — аргументов, то bash также не вызовется. Например, для Perl: system('/bin/echo', 'a', 'b') — bash не запустится, а для system(«echo a b») — запустится.

    Поправьте меня, если я ошибся где-то, пожалуйста.
    • +1
      2. Тем не менее apache (точнее библиотека APR )на каждый вызов cgi запускает /bin/sh. (1) (2)
      3. При использовании C есть два варианта: вызов system(«command») — ведет к однозначному запуску "/bin/sh -c command"(3), вызов exec(«command») ведет к вызову "/bin/sh -c command" в случае «если заголовок исполняемого файла не распознан» (4)
      • 0
        Похоже я ошибался. Тот явный вызов /bin/sh который я нашел в исходниках происходит при обработке SSI, а не CGI, хотя и размещен в mod_cgi.
        Таким образом мое утверждение о том что bash запускается на каждый старт cgi в не верно. Непосредственно подвержены эксплуатации уязвимости через apache: bash cgi скрипты, cgi использующие вызовы system(), popen(), exec() (в очень редких случаях) без очистки переменных окружения, SSI cmd.
        • 0
          SSI cmd используется весьма редко, кстати. А вот popen (вернее, open(F, "| cmd") в perl-скриптах), думаю, в 99% случаях — это вызов sendmail (вроде бы PHP тоже sendmail вызывает через popen?). Так что, скорее всего, утверждение «сайт уязвим» очень-очень сильно коррелирует с утверждением «на сайте есть форма обратной связи».

          Плюс п. 1 («Почему вообще bash пытается как-то интерпретировать содержимое переменной окружения?») так и не раскрыт же — я в других источниках тоже не видел ничего на эту тему, кстати.
          • +2
            По п.1: ru.wikipedia.org/wiki/Bashdoor

            При запуске новых экземпляров Bash из существующего bash возможна передача (экспортирование, export) значений существующих переменных окружения и определений функций в порождаемый процесс.[12] Определения функций экспортируеются путем кодирования их в виде новых переменных окружения специального формата, начинающегося с пустых скобок "()", за которыми следует определение функции в виде строки. Новые экземпляры Bash при своем запуске сканируют все переменные среды, детектируя данный формат и преобразовывая его обратно в определение внутренней функции.[13] Данное преобразование проводится путем создания фрагмента Bash-кода на базе значения переменной среды и его исполнения ('on-the-fly'). Подверженные уязвимости версии Bash не производят проверок, что исполняемый фрагмент содержит лишь определение функции.[13]…

            27 сентября был опубликован качественный патч, который добавляет ко всем экспортируемым и импортируемым функциям специальный префикс (BASH_FUNC_) при их преобразовании в переменные окружения и обратно.[14]


            git.savannah.gnu.org/cgit/bash.git/tree/variables.c?id=ac50fbac377e32b98d2de396f016ea81e8ee9961#n315 bash.git/tree/variables.c
            /* Initialize the shell variables from the current environment.
               If PRIVMODE is nonzero, don't import functions from ENV or
               parse $SHELLOPTS. */
            ...
                  /* If exported function, define it now.  Don't import functions from
            	 the environment in privileged mode. */
                  if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
            ...
            	  if (posixly_correct == 0 || legal_identifier (name))
            	    parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
            
            


            Еще вопрос — зачем в popen запуск /bin/sh… IEEE Std 1003.1, 2004 — popen: «and the child invoked the sh utility using the call: execl(shell path, „sh“, „-c“, command, (char *)0);»
  • 0
    github.com/pbkwee/deshellshock — самый быстрый способ обновить bash и проверить уязвимость.
  • 0
    OS X bash Update 1.0 – OS X Mavericks support.apple.com/kb/DL1769 очень легко устанавливается
  • –1
    Не зря я с недоверием к bash всегда относился.
    Использую zsh.
    Обновления запускаю каждый день.
  • 0
    Итак, если резюмировать вопрос уязвимости сервера, к примеру, Debian.

    Вариант №1. Посредством веб-сервера, запущенного на данном сервере. При каких условиях становится возможным эксплуатация уязвимости bash?
    Пойдём от обратного. Как я себе вижу. Эксплуатировать уязвимость bash на данном сервере считается невозможным, если у пользователя веб-сервера, от которого он работает, это к примеру, www-data, в /etc/passwd установлен интерпретатор команд не bash (идеально /bin/false). Вызовы системных команд через тот же exec () из кода будет происходить с использованием /bin/sh по дефолту, что уже известно, и в свою очередь ,/bin/sh — это dash на самом деле, и который неподвержен атакам. А также это всё верно в том случае, если работает apache+mod_fcgi или php-fpm. Иначе и говорить даже не о чём, и сервер абсолютно защищён?

    Вариант №2. Атака по протоколу ssh. Если учесть, что PermitRootLogin no, все пароли всех пользователей достаточно надёжны, и порты прикрыты acl списками по firewall-у, тогда также не стоит беспокоиться по поводу безопасности и возможности эксплуатации багов в bash?

    Просьба подтвердить или опровергнуть, что я не учёл в своих размышлениях.
    • 0
      В первом варианте Вы не учли, что Вы не можете проконтролировать код всех CGI/PHP/etc. скриптов и гарантировать что ни один из них не вызывает именно bash, а не sh или $SHELL.

      Во втором — если сервер ssh использует ForceCommand и AcceptEnv * то ForceCommand смогут обойти.
  • +3
    У нас всё работает на ПО от Microsoft, нам надо беспокоиться?
    Короткий ответ — нет

    Теперь уже ответом будет «конечно!»:
    Бельгийская ИБ-компания Security Factory обнаружила в интерпретаторе команд Windows уязвимость, открывающую возможность удаленного ввода команд. Она использует переменные окружения таким же образом, как и эксплойты для Bash.

    Авив Рафф (Aviv Raff), технический директор Seculert, подтвердил, что проблема во многом схожа с Shellshock и ей подвержены многие ОС Windows, даже Windows 10 Preview.

    threatpost.ru/2014/10/07/podobnaya-shellshock-uyazvimost-mozhet-kosnutsya-i-windows/
  • 0
    Народ срочно нужна помощь, по работе прошлый айтишник как мудак поставил админские пароли на серверные компы и благополучно исчез, т.к. единственый доступ это гостевая убунты, то сделать толком ничего не могу, а начальник серьезно так пресует…
    Я правильно разобрался в статье что используя интерпретатор смогу сделать запрос вида
    http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
    на изменение пароля?
    • +2
      man «single user mode»
    • 0
      Обычно в Убунте cgi-скрипты выполняются от пользователя www-data.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка