Критическая уязвимость в bash

Romka_Kharkov, ну так если нету никого левого, кто может там запустить гадость - значит можно не бояться.

bash можно собрать вручную из сорцов.

На крайняк его можно удалить :)

Или у вас используются какие-то специфические возможности, которых нет в других шеллах?

---------- Добавлено 27.09.2014 в 20:18 ----------

Сегодня нет, а завтра появится :) Лучше не оставлять уязвимость, даже потенциальную.

Принцип по любому верный, однако если учесть что у меня есть кое-где FreeBSD 4.x то можно только представить сколько там уязвимостей, однако там никогда никого левого не было и не будет.... такая концепция сервера...

---------- Добавлено 27.09.2014 в 19:32 ----------

Меня интересует в первую очередь возможность удаленного использования данной уязвимости, кроме как через apache (cgi) есть возможность им пользоваться?

---------- Добавлено 27.09.2014 в 19:34 ----------

Кстати да, тоже вариант, полно альтернатив. ☝

Ну раз такая хорошая контрацепция, можно переживать :)

Это должно быть только вам извесно, какие ещё на вашем сервере есть способы дёрнуть bash извне.

Это меня пугает в 4ке точно есть уязвимость позволяющая злоумышленнику без доступа ко внутренностям натворить делов. Точно знаю что TCP стек позволяет remote code execution через дыру аля heartbleed и точно знаю что ssh подвержен подобному добру.

В общем обновляйтесь поскорее. Учитывая что это БСД, можно без проблем накатать мир и обновить до 10ки ядро с компатом на 4х через сурцы (после установки мира советую еще раз перекомпилить, чтобы собралось clangом). Геморрой будет только с perlом. Но с ним всегда геморрой, по простому, вынесите его и поставьте perl через pkgng

Все что позволяет запускать софту shell скрипты на сервере.

То есть cgi mod_cgi scgi fcgi fpm dhcp suexec. По-хорошему проще обновиться, чтобы потом не плакать.

ENELIS, Я поступил иначе, на старых серверах (где апгрейды вызывают определенные трудности) прибил bash :) Про TCP стеки и ssh все понятно, но когда у вас файрволом отрезано все только "для себя", стоит ли об этом беспокоиться?

Кстати в статье про уязвимость в bash было решение через бан iptables по hex строке. На FreeBSD, наверное, можно его использовать, если bash нужен, а обновить - большой геморрой.

Не совсем понял вашу фразу про FreeBSD. Там штатные фильтры (ipfw/pf/ipf) из коробки не умеют фильтровать на L7 уровне (то есть они особо не лазят в пэйлоад пакетов).

Если у сервера есть хоть какой-то выход в интернет, хоть малейший tcp/ip демон - это уже дыра.

Можно "пропатчить" без ребута поставив pf scrub in all.

Но это работает только при условиях end-use workstation/server. На гетевеях не будет работать.

К тому же не уверен что в 4ке был pf

---------- Добавлено 28.09.2014 в 16:34 ----------

Можно на c написать фильтр и вписать его в pf loop

Или же тупо соединяться с bpf и работать напрямую

модулем ng_bpf

http://nuclight.livejournal.com/124989.html

или на с++ях

http://bastian.rieck.ru/howtos/bpf/

или через pfil, что еще проще и быстрее (даже пример есть)

http://www.enderunix.org/docs/en/pfil_hook.html

Просто никто этим не занимался, но это довольно просто.

Можно включить bpf zero-copy и подключить через python scapy и фильтровать пакеты через питона.

Кто-нибудь вообще проверил эксплуатируемость уязвимости через что-то торчащее наружу?

А то всех пугают, что вещи такого типа должны работать:

curl http://x.x.x.x -A "env x='() { :;}; echo owned > /tmp/file'"

Но попробовал с PHP5-FPM и system вызовом - не прокатило. Посмотрел на вывод команды "env" через system(...) - там всего USER, HOME и PWD. Получается только создав папку можно что-либо натворить на сервере.

С mod_cgi и spawned-fcgi ситуация иная?