Bash ShellShock: новой дыре в Linux присвоен наивысший класс опасности
В Linux обнаружена уязвимость, которой присвоен высший балл опасности — 10 из 10 (по шкале NIST). Ошибка содержится в командном интерпретаторе Bash и позволяет удаленно выполнять произвольные команды.
Чтобы быстро понять суть проблемы, достаточно взглянуть на следующий код:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Круглые скобки указывают, что определяется функция, которая затем будет вызвана. Ее содержимое должно располагаться между фигурными скобками. Ошибка заключается в том, что закрывающая фигурная скобка '}' игнорируется и при вызове функции выполняется код и за скобками.
Критический уровень опасности для всей системы возникает из-за того, что Bash часто комбинируют с другими программами, в том числе и сетевыми. Злоумышленник дистанционно может передать специально сформированную строку, которая приведет к выполнению вредоносного кода на уделенном компьютере. Например, уязвимости подвержены такие широко используемые программы, как:
- Apache;
- SSH;
- CPanel;
- Git и Subversion;
- DHCP-клиенты;
- CUPS;
- и масса других.
Вот пример атаки на OpenSSH через модификацию переменной окружения SSH_ORIGINAL_COMMAND:
ssh -o 'rsaauthentication yes' 0 '() { ignored; }; /usr/bin/id'
Будет будет запущена программа /ust/bin/id (злоумышленник, разумеется, запустит что-нибудь менее приятное).
Оперативно для некоторых дистрибутивов была выпущена заплатка, однако на следующий день оказалось, что злоумышленники «нашли дыру» в самой заплате и проблема все еще актуальна. Проверить свою систему можно следующим образом:
env X='() { (a)=>\' sh -c "echo date"; cat echo
Вторая заплатка уже готова и скоро будет распространена через службы обновлений.
Комментарии
pomodor
25 сентября, 2014 - 21:35
1. Товарищи, со всей ответственностью заявляю: это полный п...ц!
2. Но помимо прямого ущерба от творчества криворуких мудаков, есть еще и косвенный. Он заключается в том, что сбывается самое страшное предсказание виндузятников, что Linux ничуть не безопасней Windows, но из-за низкой популярности в нем не ищут дыры. Линуксоненавистники утверждали, что когда популярность начнет расти, появятся и дыры, ничем не хуже, чем в Windows. Мы не верили злопыхателям ни на секунду, но Heartbleed и теперь вот ShellShock в течении одного года заставляют задуматься.
3. Теперь миграция на свободное ПО пойдет тяжелее даже в условиях санкций. У противников появился мощный аргумент — СПО небезопасно.
sudo
8 декабря, 2014 - 09:32
Насчёт второго пункта. Общался с человеком, специалистом в области «защиты и проникновения», так вот от него слышал мнение, что Linux хуже защищена, чем Windows. Это было до шеллшок.
Лично я с ним не согласен. Linux система значительно обыгрывает тем, что порог вхождения в неё выше. Винду может освоить любая домохозяйка и ей впарить троян под видом какого-нибудь антивируса намного легче, чем подсунуть linux-админу какой-то посторонний патч.
Насчёт хертблид — а разве дело только в linux? Вообще ж в библиотеке дело, не только линуксовой. Насчёт санкций — зря вы так. Вовсю уже разрабатывают отечественные дистрибутивы на базе Linux с проверенным по.
Чингачгук
26 сентября, 2015 - 14:32
А что, каждый тут сидящий лично сделал аудит кода на тему закладок, дырок и всего такого у всего чем пользуется? Загрузчик, ядро, шелл, иксы и всё остальное:) Или надеется что кто-нибудь что-нибудь нехорошее за него откопает? Вот и вся модель безопасности Open Source во всей красе.
pomodor
25 сентября, 2014 - 21:41
На серваке с Либератумом это тоже было. Пофиксил, но хрен его знает, может успели троян подсадить. Настораживает сильно возросшее время подключения по SSH.
Texnoline
26 сентября, 2014 - 07:16
на серверном юните с Ubuntu 12.04 LTS, ядро, версии: 3.12.18-031218-lowlatency
такой проблемы не обнаружил...:)
на десктопной Бунте 14.04 LTS со стоковым ядром, версии: 3.13.0 — данная проблема, также в ходе проверки, не обнаружена!:(
Автор ресурса, может — это «все пурга», или Debian в одночасье стал дрявым!??????? О..., Господи, что я пишу....
pomodor
26 сентября, 2014 - 22:43
А при чем здесь дистрибутив и тем более версия ядра? Дырка в Bash, который вездесущ. Подверженные уязвимости версии Bash можно найти тут. С 1.14.0 до 4.3. Другими словами, уязвимость в каждом линупсе страны. И самое страшное, в роутерах, модемах, точках доступа, NAS и т.п.
А при чем тут Дебиан? Bash запилил негр Брайан Фокс, а не Ян Мердок. И Debian является единственным дистрибутивом, который можно использовать для серьезных проектов. Все остальное — для домашних забав энтузиастов. Дырявым он не был и не стал.
Texnoline
26 сентября, 2014 - 23:07
при том, что указывал специально для сомневающихся, коих большинство, потом чтобы не орали, что не указал версию дистра и на каком ядре сижу!?:(
Я проверил способом указанным в статье, нет уязвимости, и проверил несколько раз перед комментом!:(
Я в курсе, кто написал bash, и кто создал Дебиан!;)))
Не только правоверный Дебиан используют компании для серьезных проектов, есть ряд и других, не менее оптимальных дистрибутивов для серьезных тем!?;)
pomodor
26 сентября, 2014 - 23:22
Ну это если уж совсем дебилы. В тексте же написано, что это bash скобку не проверяет.
Только RHEL/CentOS на ум приходит.
Texnoline
26 сентября, 2014 - 23:36
Автор, а вы думаете, что больщинство — всЁ гениальное через один????????????
Добавим и Ubuntu Server c ядрами низкой латентности, как не менее стабильный вариант по сравнению с Центом!?:)
pomodor
27 сентября, 2014 - 00:05
Первый вопрос не понял. Думаю ли я, что стоящие дистрибутивы можно пересчитать по пальцам одной руки? Да, я в этом уверен!
А зачем на сервере низкая латентность?
Texnoline
27 сентября, 2014 - 07:41
первый вопрос был, скорее риторический;)... о большинстве с IQ менее 45!?;) о тех самых дебилах, если по простому...
подходящих дистров всегда было до 5 штук максимум, все остальное — это эксперименты долговременные или короткоживущие!
Низкая латентность на «боевых серваках":
1. за счет низкой латентности ядра, существенно увеличивается быстродействие в операциях с интенсивным обращением к различным сегментам памяти.
2. уменьшение времени отклика в обработки медиа-задач при стримминге, актуально в медиа-ресурсах сетевых...
3. необходимость в планировки высокоприоритетных задач, особенно при кластерных конфигурациях...
4. обработка больших объемов данных, сфера социальных сетей и Big Data.
5. реалтайм в узких задачах в промышленной области, САР и АСУ!:)
pomodor
27 сентября, 2014 - 19:25
Низкая латентность приводит к снижению производительности, так как возрастают затраты на частое переключение контекста. Растет отзывчивость системы, что приятно на десктопе, но совершенно бесполезно на сервере.
За счет чего оно может расти?
Единственная область, где действительно может потребоваться низкая латентность, то тут уже принято Linux менять на QNX.
Texnoline
27 сентября, 2014 - 19:58
Когда на сервере в стойке, на каждом 2U-юните до 20 ядер, типа: Lenovo ThinkServer RD640 (2 x 10-ядерный Intel Xeon E5-2660V2 2200 МГц; RAM — до 320 Gb), то при использовании низколатентных ядер, можно получить реальный прирост производительности при интенсивных обращениях к памяти в ряде задач. При этом общей суммарной производительности вполне достаточно, чтобы не замечать просадок, при частом переключении контекста...:)
QNX, не везде и не всегда используется в промышленном секторе, когда работал в БАЗЭЛЕ, мы изучали вместе с проектным институтом, данный вопрос, и остановились на использовании одного из дистрибутивов deb-based c низколатентным ядром, как оптимальное сочетание множества факторов....
pomodor
27 сентября, 2014 - 21:47
Ну хотя бы на класс задач намекните, раздирает от любопытства. :) Процесс получает 10 мс вместо 100 мс на беспрерывную работу. Грубо говоря, программа чаще прерывается, но вдруг откуда-то возникает прирост производительности. :)
Ну, это понятно. Но если требуется настоящий real-time, то даже Линукс не очень подходит из-за особенностей архитектуры.
acpid
26 сентября, 2014 - 12:46
В арче вчера обнаружил проблему, ради интереса обновился: заплатка прилетела, а вторая дыра, насколько я понял, так и осталась незакрытой, сегодня ещё проверю.
pomodor
26 сентября, 2014 - 18:01
В Debian и вторую вчера еще прикрыли
Texnoline
26 сентября, 2014 - 23:32
альтернативный временный вариант, для тех у кого все таки есть данная «кака.." в bash:( :
iptables --append INPUT -p tcp -m string --algo kmp --hex-string "|28 29 20 7B|" -j DROP
Может и пригодиться, когда истерика в глобальном масштабе, достигнет своего кармического пика!
pomodor
27 сентября, 2014 - 00:12
Очень плохая идея. Во-первых, проверяется весь трафик на вхождение этой подстроки, что требует значительных ресурсов. Во-вторых, не учитывается контекст — сброс всех соединений, по которым пролетает "() {" грозит серьезными и трудно отлавливаемыми проблемами. Уж проще вручную исходники Bash пропатчить, если разработчики дистрибутива спят.
Чингачгук
20 августа, 2018 - 19:59
FreeBSD вращает линух с виндузой на болте с левой резьбой )))
Texnoline
21 августа, 2018 - 02:17
Ну,ну - а пингвин смеется:)
1. в 11/10/8 версий - в сетевом стеке ошибка - расшифрованный трафик на GIF-интерфейс не направляется, вместо этого он снова попадает на внешний интерфейс, как входящий пакет, но уже с внутренними айпи...!?:)
2. проблема с samba 4 - с отображением папок и файлов на русском языке в расшаренных папках. Они просто не отображаются совсем!
3. Mounting from ufs: /dev/ad0s1a failed with error 19 - уже пофиксили, или еще встречается!?
pomodor
22 августа, 2018 - 12:52
Вращал во времена 4. С тех пор поциент скорее мертв, чем жив и уж тем более никого не вращает ни на какой резьбе.
Комментировать