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)

даешь bashd в следующем релизе от Ленчика!

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

Никаких выкручиваний, просто трансляции символов недостаточно для uppercase.
Но для немецкого языка можно сделать вот так: 9 tr 'a-zà-þ' 'A-ZÀ-Þ' | sed 's/ß/SS/g' (уж не знаю, правильно так делать или нет).

quantum-troll ★★★★★
()
Ответ на: комментарий от darkenshvein

Ну там от простого сетевого запроса может упасть. Так что не спасёт.

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

И ставь Win? Win на сервере то еще говно, если не нужны конкретные технологии Microsoft.

Или мсье поклонник OS X?

xasecoro
()

Спасибо за новость, анончик. Интересный и неведомый ресурс по Perl'у спалил мне.

fero ★★★★
()

RedHat подготавливает площадку для внедрения bashd!

Shadow1251
()

В 6-м дебиане исправлений нет. Не знаю, может, и логично, он ведь уже как олд. Но на него ставится bash с зависимостями libtinfo5 и multiarch-support от 7-го.

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

точнее так, наверно

xsektorx ★★★
()
Ответ на: комментарий от quantum-troll

Я не только про tr, мне вообще интересно, есть ли еще способы

% export A='фѣљъ Straße'
% bash -c 'echo ${A^^}'
ФѢЉЪ STRAßE
% awk '{ print toupper($0) }' <<< $A
ФѢЉЪ STRAßE
% /opt/plan9/bin/awk '{ print toupper($0) }' <<< $A 
фѣљъ STRAßE
% gawk '{ print toupper($0) }' <<< $A
ФѢЉЪ STRAßE
% perl -CS -pnE '$_=uc' <<< $A
ФѢЉЪ STRASSE
В итоге только perl умеет в юникод? awk из plan9 у меня почему то даже на љ зафейлился

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

уж не знаю, правильно так делать или нет

Не, ß(эсцет) только один из символов, которые так транслируются. Кроме того в юникоде еще много неожиданных вещей, вроде того что ۶۵٩໓𝟜 - цифры

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

awk из plan9 у меня почему то даже на љ зафейлился

Проблема в том, что plan9 — слишком suckless для юникода.

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

Ну нафиг, лучше coreutils на node.js и выкинуть bash совсем.

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

говнокод на javascript чем оличаятся от говнокода на ц? тем что больше жрёт и тормозит

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

Почему у тебя на аватаре адидас с четырьмя полосками?

anonymous
()

Тысячи глаз прочёсывают коды свободных проектов и выявляют баги и уязвимости одна за одной.

И используют их в своих корыстных целях. А вы как думали?

anonymous
()

Пойду пилить своё окружение для себя...

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

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

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

Фигню написал.пнг

GC - это только server-side, на клиенте за такое клиенты могут побить. Батарейка у девайсов не резиновая, а лэптопы около розеток - это для 0.1% гиков. Детерменированные ARC/smart pointers - это way to go, а не серверные слонопотаморантаймы.

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

всем насрать на твою генту и ебилды. Зачем мне смотреть ебилд, если я собираю пакеты лучше чем всё гентокоммунити сразу, и у меня эти грёбаные уязвимости не работают?

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

Теперь ваш Баш может выполнить любые команды? Вот это поворот, невероятно!

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

и у меня эти грёбаные уязвимости не работают?

Ну и молодец возьми себе печеньку с полочки.

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

Давно пора перейти на systemd вместо дырявых портянок на shell.

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

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

Exim, qmail

Что-то не соображу, а в каком месте ? MTA где-то вызывает шел при обработке сообщения !?

procmail

Вот тут понятно, если доходит до procmail... Кстати, ругаемый всеми Sendmail давным давно запускает procmail c smrsh, если используется FEATURE smrsh, что рекомендуется.

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

По ходу достаточно весомый аргумент против инициализации на шелл-скриптах.

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

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

ведь очевидно, что половина проблем

сам бог велел писать на ещё более высокоуровневом языке

Это исключительно ваши измышления. Простая фильтрация CVE List демонстрирует, что в тех же Java и .NET число уязвимостей весьма и весьма впечатляющее.

Поэтому баги bash останутся на совести исключительно разработчиков bash, а язык ни при чем.

northerner ★★★
()

openSUSE 13.1:

$ ./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

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

Пока ты писал сообщение нашли ещё 23уязвимости Гг ) Проверил фряшки, баша нет, всё гут) на бунте есть\ rm -rf bash & use sh :D

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

Я это первым делом на серверах делаю.

Чем это поможет? У тебя от этого все зависимости от app-shells/bash дропнутся и автоматом выполнится emerge -C app-shells/bash?

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

MTA где-то вызывает шел при обработке сообщения !?

Может вызывать, если в .qmail есть доставка через программу (|/bin/procmail). При этом в переменную SENDER попадает то, что было в mail from:<> SMTP-диалога.

http://www.gossamer-threads.com/lists/qmail/users/138578

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

если в .qmail есть доставка через программу (|/bin/procmail)

Я вариант с procmail упомянул отдельно. С ним (и подобными вариантами) всё понятно. Только это же не проблема MTA, как такового, это раз, а два, неужели Postfix не уязвим примерно так же ? Почему он отмечен, как неуязвимый ?

А, вообще, давно уже практика должна была быть сведена к MTA -> lmtp -> Mail Storage.

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

1) Упаси боже, чтоб большая часть лоровцев вообще лезла в код.

2) Альтернатив нет. Думать надо лучше и баги фиксить.

3) А сколько раз были баги-уязвимости в самой ява-машине или .net?

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

Отлично!

Чертовски приятно увидеть на данном ресурсе подобный комментарий. Поддерживаю руками-ногами :) Ибо от большинства остальных комментариев ощущение, что писали их случайные двуногие обезъяны, по ошибке вместо ВКонтактика попавшие сюда...

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

Много ли ЛОРовцев могут прямо сейчас влезть в код и его починить ?

Я чинил, когда доставало и наступало понимание, что за меня именно эти баги фиксить никто не будет, или нужные фичи добавлять.

Сколько им понадобится времени на нахождение, фикс, отладку и публикацию в мир ?

Зависит от организации проекта и опыта того, кто полез править. Ну и от масштаба исправления.

аж со времён ... (когда «память - больше не проблема»)

Я не вижу этих времён. Такие вот мышевозилы гуёвые её успешно потребляют. Всю, что есть. На несколько вкладок FireFox уже не хватает 1Гб (!) RAM. Просто полазить по сйтикам... Тьфу... Вспоминается анекдот про агронома и колорадского жука. Купил себе бук, добил до 6Гб, пока жизнь есть. А на долго ?..

У всех с bash паника. А, на деле, найдите вот дистрибутив, где у сервисов не /bin/false в качестве шела. Да, для web это опасно, что-то там подсунуть, безусловно, можно, а в остальном ? Тут же вот, про OpenVPN, примечание: при доступе на сервер злоумышленника. Ну так ты не лазий в непроверенные места. Git - тут, наверное, да, беда. Но размер катастрофы, всё равно, сильно преувеличен на мой взгляд. Некоторые пишут, что это серьёзнее недавней проблемы с ssl. Так вот, думаю, что не серьёзнее ни разу. Давать шелл опасно само по себе, так что, во многих случаях, пострадают или сами себе буратины, или у кого выхода не было. Последние, очевидно, уже обновились.

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

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

Они хотя бы нашли уязвимость, и скоро закроют, а как же обстоит дела с шиндовс, умник?

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