LINUX.ORG.RU

В Red Hat и Fedora выявлена удалённая root-уязвимость в DHCP-клиенте

 ,


3

4

Феликсом Вильгельмом, из команды «Google Security», в скрипте интеграции с NetworkManager, входящем в состав пакета dhcp-client, предлагаемого в Red Hat Enterprise Linux и Fedora, была выявлена критическая уязвимость (CVE-2018-1111), которая позволяет удалённо выполнить код с правами root.

Вот сам код

 eval "$(
   declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
       optname=${opt%%=*}
       optname=${optname,,}
       optname=new_${optname#dhcp4_}
       optvalue=${opt#*=}
       echo "export $optname=$optvalue"
   done
   )"

Как это работает?

Протокол DHCP используется для настройки сетевой информации в хостах с центрального сервера. Когда хост подключен к сети, он может выдавать запросы DHCP для получения параметров сетевой конфигурации, таких как IP-адрес, IP-адрес маршрутизатора по умолчанию, DNS-серверы и т.д.

DHCP-клиент, предоставляемый Red Hat, имеет скрипт /etc/NetworkManager/dispatcher.d/11-dhclient (в Red Hat Enterprise Linux 7) или /etc/NetworkManager/dispatcher.d/10-dhclient (в Red Hat Enterprise Linux 6) для компонента NetworkManager, который выполняется каждый раз, когда NetworkManager получает ответ DHCP с сервера DHCP. Злоумышленный ответ DHCP может заставить скрипт выполнять произвольные команды оболочки с привилегиями root.

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

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от kirk_johnson

Ну хорошо, как «перепишем ведро на жабе» тогда и поговорим. Кстати забыл... надо же еще процы пофиксить перед этим (намек на мелдоний спектральный), а то в «крузис» не поиграть будет.

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

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

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

Не перепишем. Это вряд-ли выйдет лучше.

Не, ну почему? Контроллеры с rt «програмят» на жабе. :)
Ша процы помощнее выпустят, и пойдем «переписывать»... :)

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

Не, ну почему? Контроллеры с rt «програмят» на жабе. :)
Ша процы помощнее выпустят, и пойдем «переписывать»... :)

Дело в количестве времени, которое потребуется затратить, а не в языке.

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

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

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

Где там парсинг протокола на шелле? Это скрипт запуска аналогичных по смыслу скриптов dhclient-а для обратной совместимости. Которые юзается для того, чтобы прокидывать допольниетльные параметры сообветсвующим демонам, например, список ntp-серверов в ntpd.

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

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

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

Если в метро действительно ноутбуками пользуются мало, в основном смартфонами и планшетами, то в кафешках, аэропортах и т. д. ноутбуки вполне себе в ходу...

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

И что? Это не меняет того, что

выносят из дома

подключаться к сетям на работе, в аэропортах, кафешках и т. д.

уже на свой страх и риск. Тут можно наступить не только на сабжевые грабли.

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

Но я считаю, проблема в баше - он слишком примитивен для таких вещей. Элементарного искоробочного pattern matching нет.

Знатоки баша в этом чате, все в csh!

Примитивен не баш, а твои знания о нём. Pattern matching, и многое другое, там есть из коробки. Проблема в том, что им не пользуются, так как скрипты пишут либо такие же знатоки как и ты, которые ещё и shellcheck не осиливают к редактору прикрутить, либо sh-пуристы, считающие «башизмы» недопустимыми, бормочущие что-то там про переносимость на какие-то неизвестные никому системы, где нет bash, и потому городящие совершенно невообразимые конструкции из костылей и подпорок.

Впрочем, это не отменяет того факта, что скриптовать на баше безопасно тяжело. Язык не располагает к этому совершенно, даже с включением т.н. «unofficial strict mode», который в свою очередь вызывает у нубов разрыв шаблона и зуд пониже спины. Вопрос на чём лушче скриптовать подобное всё ещё остаётся открытым, тем более если учесть насколько поляризовано общество «правильных программистов» и «юникс-ветеранов» в отношении скриптовых языков. А так-то Питон сгодился бы на ура.

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

Я благодарен за участие.

Хотел бы уточнить, тот парсинг переменных, содержащих строки вида *DHCP*=*, может ли быть осуществлен как-то по-другому на баше? Либо, как-то по-другому, по-твоему, осуществить передачу параметров в скрипт 11-dhclient?

Проблема в том, что им не пользуются, так как скрипты пишут либо такие же знатоки как и ты

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

скриптовать на баше безопасно тяжело

Ок, я уже сталкивался, что моё понятние «примитивный» - некорректно. Я тоже имею ввиду «тяжело», «сложно». («примитивный» в том же смысле, как ассемблер)

Питон сгодился бы на ура.

Мне лично не нравится, как в питоне синтаксически выглядят элементарные функции баша - запуск процессов, перенаправление io. И некоторое количество boilerplate code в тривиальных скриптах. (Справедливости ради, в баше, включая все нужные set -o, его не меньше). Это останавливает от его использования. Логика же на нем идет отлично, да.

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

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

Хотел бы уточнить, тот парсинг переменных, содержащих строки вида *DHCP*=*, может ли быть осуществлен как-то по-другому на баше?

тут ведь не в парсинге проблема, а в последующем eval. которая спокойно решается

result=$(...)
eval ${result@Q}
ananas ★★★★★ ()

Я бы этот баш вообще запретил. Юзать для критичных системных компонентов язык со сломанной подстановкой переменных и с eval - это даже не идиотизм, это саботаж.

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

А по факту оказывается кривая баш-портянка на стыке IPC при передаче параметров. Очень символично. Хейтеры на c-д валят столько несуразицы, что порой кажется - с-д лучшее ПО, т.к. фактические проблемы единичны.

Что не отменяет недальновидности разрабов, которые завязались на bash.

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

Ерунду ты придумал. Systemd как раз вполне разумна убрал исполняемый код из юнитов. В данном случае инит вообще не при чем. Такую же ерунду и на сишечке можно намутить.

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

Примитивен не баш, а твои знания о нём.

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

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

Может просто стоило распарсить протокол в другом месте и передать список серверов вот так:

NTP_SERVERS='foo bar baz' /path/to/script

Даже eval никакого не нужно =/

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

Может просто стоило распарсить протокол в другом месте и передать список серверов вот так:

Оно так и сделано. Протлокол dhcp распарсен «в другом месте», но в коде в оп-посте распарсенное перекладывают из кармана в карман и фейлят.

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

в данном конкретном случае, по хорошему, уже на уровне grep-а можно было много чего сделать. я же просто хотел показать, как достаточно просто обезопасить eval (в общем случае)

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

И в 100 раз я уверяюсь в своем мнении - выбор языка для systemd-юнитов был неправилен. Это должно было быть что-то более гибкое и удобное, и впоследствии заменить bash в таких вот вещах, как сабжевый скрипт. Но в результате, юниты пишутся на недоязыке а-ля ini-файлы, с вкраплениями того же баша.

Tcl. Песочница встроена.

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

Потому что в RHEL7 по дефолту ставится rsyslog который читает структурированные данные из journal и занимается их хранением и/или пересылкой дальше куда скажут.

Придумали целый journald с блекджеком лишь для того, чтобы кидать логи в rsyslog. Суровые люди.

devzero ()

Честно говоря, не понимаю, почему не написали по-человечески, без eval и read. Это же гораздо проще:

DHCP4_TEST=teststr
DHCP4_WS='whitespace separated'
DHCP4_BACKSLASH_AND_N='\n'
DHCP4_NL=$'new\nline'
DHCP4_EXPLOIT="exploit'&date #"
for optname in "${!DHCP4_@}"; do
    newoptname=${optname,,};
    newoptname=new_${newoptname#dhcp4_};
    export $newoptname="${!optname}";
done

#see what's done
sh <<"TEST"
for i in "${!new_@}"; do
    y=${!i};
    printf '%s=<<%s>>\n' "$i" "${y}";
done
TEST

Выхлоп (эксплоит не работает, данные не испорчены):

new_backslash_and_n=<<\n>>
new_exploit=<<exploit'&date #>>
new_nl=<<new
line>>
new_test=<<teststr>>
new_ws=<<whitespace separated>>

Для сравнения, оригинальный код выводит это:

new_backslash_and_n=<<n>>
new_test=<<teststr>>
new_ws=<<whitespace separated>>
На параметре с переводом строки он падает, на эксплоите он эксплуатируется.

legolegs ★★★★★ ()