LINUX.ORG.RU

Обнаружены новые уязвимости в bash

 , shellshock


3

3

Не успело сообщество отойти от уязвимостей ShellShock, как сотрудник Red Hat Флориан Ваймер опубликовал информацию о новых. Уязвимости CVE-2014-7186 и CVE-2014-7187, возникающие из-за некорректной обработки операций с памятью при разборе выражений, перечёркивают все прошлые усилия по закрытию ShellShock и позволяют удалённо выполнять любые команды.

Протестировать наличие проблем CVE-2014-7186 и CVE-2014-7187 можно при помощи выражений:

   bash -c "true $(printf '</dev/null
   if [ $? != 0 ]; then
      echo -e "Vulnerable to CVE-2014-7186"
   fi

   bash -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

Пользователи FreeBSD и NetBSD вне опасности, поскольку тамошние мейнтейнеры решили пожертвовать обратной совместимостью и полностью отключили эту часть функционала bash.

Ещё две уязвимости CVE-2014-6277 и CVE-2014-6278 обнаружил сотрудник Google Михаил Залевский, но отказался публиковать подробности до внесения исправлений в bash. Учитывая, что для разбора кода функций в bash применяется большой универсальный пласт кода, который потенциально может предоставлять множество различных векторов для атак, так как данный код написан без оглядки на обработку данных, поступающих извне, неизвестно сколько ещё уязвимостей нас ожидает впереди.

Кроме того, можно отметить статью разработчиков Perl, в которой описываются пути проявления уязвимости в perl-скриптах, запускаемых в системах, в которых bash используется как /bin/sh и $SHELL. Проблемы могут проявляться в скриптах, в которых используется вызовы system и exec без разделения аргументов или при открытии потока через open с перенаправлением вывода. Проблемы не специфичны для Perl и проявляются в любых других языках, позволяющих выполнять команды с использованием командной оболочки.

Также опубликован дополнительный анализ возможных серверных систем, в которых возможно проведение атаки. Кроме упоминавшихся ранее атак на DHCP-клиенты, CGI-скрипты и ssh-аккаунты для Git/Subversion, в обзоре утверждается о вероятном проявлении проблемы в OpenVPN (при соединении с сервером злоумышленника), Exim, qmail, procmail, Mailfilter, SER, Phusion Passenger, Radius-серверах и службах Inetd (например, tcpserver). Не подвержены проблеме Postfix, stunnel, OpenBSD inetd и xinetd.

Для комплексной проверки систем на подверженность атакам Shellshock подготовлен универсальный скрипт.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Последнее исправление: ymn (всего исправлений: 1)

Ответ на: комментарий от Deleted

В дебиане то на dash перевели по дефолту для sh давно. #!/bin/bash и, впрочем, всё равно остались.

В gentoo от app-shells/bash зависят:

$ equery d app-shells/bash
 * These packages depend on app-shells/bash:
app-admin/eselect-mesa-0.0.10 (>=app-shells/bash-4)
app-admin/perl-cleaner-2.16 (app-shells/bash)
app-shells/bash-completion-2.1-r2 (>=app-shells/bash-3.2)
app-text/xmlto-0.0.26 (app-shells/bash)
games-util/steam-launcher-1.0.0.48 (app-shells/bash)
sys-apps/portage-2.2.8-r1 (>=app-shells/bash-4.2_p37[readline])
                          (<app-shells/bash-4.2_p37)
                          (>=app-shells/bash-3.2_p17)
sys-apps/rescan-scsi-bus-1.57-r1 (app-shells/bash)
sys-devel/crossdev-20140118 (app-shells/bash)

И во всём этом самое страшное и суровое sys-apps/portage и была правда затея с libbash на насколько я знаю ничего путного там так и не вышло.

А так то да заменить для конкретного юзера не проблема однако даже на что перевести #!/bin/bash разницы мало если основные системные компоненты один хрен требуют bash.

init_6 ★★★★★
()
Ответ на: комментарий от anonymous

разве zsh не совместим с башизмами?

Я исхожу из обратного - если бы zsh был бы полностью совместим с bash то наверное и глобальная замена не вызывала бы попоболи и подобные топики не привлекали бы такого внимания.

init_6 ★★★★★
()
Ответ на: комментарий от anonymous

самое странное что вторая *РАБОТАЕТ* на android и openwrt на ash.

А вот это вообще шикарно.

Ждём обновлений и последующих за ними внезапных поломок в самых неожиданных местах.

init_6 ★★★★★
()
Ответ на: комментарий от anonymous

У меня она в роутере на бизибоксе сработала. Команда вернула $?=2, но вроде написано что уязвимость бестолковая: позволяет атакующему изменить переменную к которой у него и так есть доступ...

Упс.. не сработало.. бизибокс ее вообще кушать не хочет. Два - это код ошибки.

naszar
()
Последнее исправление: naszar (всего исправлений: 1)
$ bash -c "true $(printf '</dev/null
>    if [ $? != 0 ]; then
>       echo -e "Vulnerable to CVE-2014-7186"
>    fi
> 
>    bash -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
> 
> 
> 
> 

Как это вообще запускать?

skvitek ★★★
()
Последнее исправление: skvitek (всего исправлений: 1)
Ответ на: комментарий от anonymous

LOR-овское форматирование запиливали по дичайшей накурке. А ещё оно не работает так, как от него ожидаешь. Казалось бы, \" и '>' не должны ничего нарушать в блоке 'code' - но неееет же.

skvitek ★★★
()
Последнее исправление: skvitek (всего исправлений: 2)
Ответ на: комментарий от anonymoos

полностью согласен

это надо додуматься устанавливать переменные извне в енваиронмент на сервере, даже без известных уязвимостей это ссзб дикое

unt1tled ★★★★
()
Ответ на: комментарий от init_6

Для gentoo app-shells/bash-4.2_p49:

./bashcheck
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./bashcheck: line 18:   537 Ошибка сегментирования                   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)

Непофикшено CVE-2014-7186 и CVE-2014-6277 но там уже куча новых ebuild-ов готова.

init_6 ★★★★★
()
Ответ на: комментарий от skvitek

На 4.2 и 4.3 не работает, штоле?

Скачай и проверь. Выше я написал вполне конкретную версию ebuild-а и выхлоп bashcheck.

init_6 ★★★★★
()
Ответ на: комментарий от Legioner

«Действительно. Тысячи глаз прочёсывают коды свободных проектов и выявляют баги и уязвимости одна за одной. Свободный софт становится всё безопасней, в отличие от проприетарщиков, которые даже отрепорченные баги не торопятся исправлять.»

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

anonymous
()
Ответ на: комментарий от anonymous

strace

ага, я об этом забыл/не знал.

anonymous
()
Ответ на: комментарий от skvitek

Ну и я бы сказал для кого ебилды - у меня сорт оф LFS в продакшне и на ноуте.

Зашел packages.gentoo.org -> app-shells/bash ткнул на ebuild-ик дальше полазил и нашел там app-shells/bash-4.2_p49 с 80-й строчки увидел патчики которые можно найти вот там. А в самом ebuild-е так же можно найти и все параметры сборки и вообще всё что portage делает и до сборки и после сборка пакета.

Так что насрать что там у тебя. Хоть SlackWare!

init_6 ★★★★★
()
Ответ на: комментарий от anonymous

самое странное что вторая *РАБОТАЕТ* на android и openwrt на ash.

Боюсь, теперь отложат релиз OpenWRT... они и так должны были где-то в конце августа-начале сентября выкатить либо очередной RC, либо релиз, но вот уже месяц как тянут. А жаль, там много вкусного в релизе, один аналог systemd чего стоит.

anonymous
()
Ответ на: комментарий от anonymous

что значит «по умолчанию»? /bin/sh слинкован на него? тогда вот так проверяй:

grep -rl -e '^#/usr/bin/bash' -e '^#/usr/bin/env bash' /
xsektorx ★★★
()
Ответ на: комментарий от Deleted

sh это не для юзера, у юзеров как был bash так и остался.

Вообще та самая тема это выпилить вообще все интерпретаторы. Потому-что не bash-ем единым… В системе как правило ещё и perl, python, lua, ruby… и, как говорится, понеслась!

И то что так активно взялись за bash конечно очень замечательно. Но по сути то в любом интерпретаторе потенциально могут быть ещё и не такие баги.

Ну а если и не полностью выпилить то по возможности как-то оградить их от всего остального так чтобы песочница не дала бы навредить.

init_6 ★★★★★
()
Ответ на: комментарий от anonymous

Лол, как раз данный баг, который присутствовал в системе годами, эти хваленые тысячи глаз не нашли.

Программ без багов не бывает. Вопрос в их количестве, скорости нахождения и исправления.

Страшно представить, что сделали за эти годы хакеры, обладавшие сакральным знанием.

Страшно - не представляй. Ни один адекватный безопасник не уповает на то, что в каком-то софте нет багов. Для этого и делают многоуровневую защиту.

Legioner ★★★★★
()
Ответ на: комментарий от init_6

Вот только более другие «интерпретаторы» таки ЯП, а баш это «палка, палка, огуречик». Нет нормальных типов данных, постоянные проблемы с экранированием, сабшеллы и прочая лабуда.

Deleted
()
Ответ на: комментарий от anonymous

Вот вам и хваленная ШВАБОДНАЯ безопасность

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

CHIPOK ★★★
()
Ответ на: комментарий от init_6

Dash:

$ dash 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
Agweb
()

Не подвержены проблеме Postfix

В определённых, недефолтных условиях — подвержен т.к. procmail.

x3al ★★★★★
()

bashcheck on debian

Выхлоп bashcheck на debian jessie и wheezy после установки последних обновлений:

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

anonymous
()
Ответ на: комментарий от anonymous

Так если у меня по умолчанию zsh?

Не имеет значения. На рхел подобных /bin/sh это симлинк на bash.

zloelamo ★★★★
()

Я же говорил, что эпично, а вы мне не верили.

WARNING ★★★★
()

То-то у рхел7 обновления к баш два раза прилетали.

imul ★★★★★
()

Все больше кажется что пора отключаться от интернетов. Нет интернета- нет уязвимостей

disee ★★★
()
Ответ на: комментарий от Agweb
$ cat /etc/issue
Fedora release 20 (Heisenbug)

$ rpm -q bash
bash-4.2.48-2.fc20.x86_64

$ ./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 bugs
Deleted
()
Ответ на: комментарий от quantum-troll
% echo 'фыъ Straße'|tr '[:lower:]' '[:upper:]' 
фыъ STRAßE

% echo 'фыъ Straße'|/opt/plan9/bin/tr '[:lower:]' '[:upper:]'
фыъ Straße

plan9 tr не умеет метаклассы?

Ну ок, как мне с этого получить нормальный юникодный uppercase?

echo 'фыъ Straße'| ???
ФЫЪ STRASSE

disarmer ★★★
()
Ответ на: комментарий от ii343hbka

Исправить самому. В чём сложность? Кросс-компилятор в одну руку, скрипты для пересборки deb-пакета — в другую и вперёд! А вообще пора выкинуть этот мертвый телефончик и купить Jolla.

EXL ★★★★★
()

В любом продукте есть дыры, но если взглянуть на них через призму FOSS и преимуществ, которые выдвигают апологеты Линукса, получается картина не намного лучше проприетарных поделий:

1. Да, код открытый. И ЧТО? Много ли ЛОРовцев могут прямо сейчас влезть в код и его починить? Сколько им понадобится времени на нахождение, фикс, отладку и публикацию в мир? Думаю, даже больше проприетарного, потому что в закрытом коде ОДИН разработчик (BTW постоянно работающий над кодом) и он знает, где-что-как. В FOSSе никто никому ничего не должен, даже сам автор программы. Соизволит - починит, а будет занят - считай, всё ложится на плечи абсолютно посторонних людей.
2. Удручает качество кода. Неужто когда писалась вся эта лабуда, автору не пришло в голову, что данную архитектуру можно хакнуть? (как видим, даже без особых хитростей по обману юзера) Почему потенциально дырявые места даже не помечаются как проблемные? Не потому ли, что сам С/С++ суть решето замедленного действия и бессмысленно помечать каждую первую строчку? :)
3. Странно, что аж со времён Java (когда «память - больше не проблема») никто не озадачился переходом на более безопасный язык - ведь очевидно, что половина проблем - как раз из-за ручного влезания в механизмы, где человеческий мозг просто не в состоянии удерживать всё в голове. Тот, кому «нехватает ручного управления» либо слишком умный (0.000001% прогеров), либо очень глупый и своей тупой настырностью только лишний раз подвергает код ненужным опасностям. Большинство софта СПОКОЙНО обходятся GC - достаточно взглянуть на .NET;
Соответственно, если бы линуксоиды поменьше переписывали «скрипты загрузки» и «пакетные менеджеры», у них появилось бы время подумать о переходе на другие языки - ту же Жабу в своё время можно было сделать компилируемой. Или подхватить Ди - ещё лучше идея.
Линукс даже в системной части не нуждается в ассемблере - спокойно пишется на Си. А уж перделки вроде «ls» сам бог велел писать на ещё более высокоуровневом языке, чтобы повышать надёжность системы.

Вот такие вот грустные мысли... Почему грустные? Да потому что всем нас-рать - Торвальдс купается в лучах славы, космонавт пилит десктоп, красношляп пилит бабло, а перетряхнуть основы решета - никто на это не отваживается даже в рамках консольных утилит (хотя почему-то вещи вроде Perl-linux нашли себе место). Вот такой он, пингвинукс - ещё консервативнее замшелых «банковских систем на Коболе»!

matumba ★★★★★
()
Ответ на: комментарий от disarmer

plan9 tr не умеет метаклассы?

Да, не умеет.

Ну ок, как мне с этого получить нормальный юникодный uppercase?

Никак, и вот почему: tr означает translate characters. Т.е он переводит символы в символы, ну или удаляет их, но не переводит символы в строки. А «SS» — уже строка.

quantum-troll ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.