LINUX.ORG.RU

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

 ,


4

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 ()
Последнее исправление: beastie (всего исправлений: 3)

А кто его туда добавил? В git-e должно же быть.

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

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

anonymous
()

Опять баш-лапша просочилась сквозь друшлаг.

Когда уже Red Hat убьёт нафиг этот шелл и сопутствующие ему дырявые скрипты?

EXL ★★★★★
()

Использовать шелл для парсинга протокола, да еще и от рута... Это праздник какой-то.

Не зря я снова OpenBSD начал донатить.

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

Надеюсь, жизнь у него будет такая же никчёмная и маргинальная, как у ещё одной лапши — SysVinit.

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

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

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

Тут есть небольшая разница — шелл скрипты sysvinit'а не парсят произвольный юзерский ввод.

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

А кем вообще переменные окружения *DHCP4_* заполняются?

Но, конечно согласен, определенно. Парсить передачу key=value значение костыльной копипастой... нда. В bash до сих пор нет pattern matching, упущение-с

Deleted
()

Забавно, что у shellcheck есть предупреждение для таких случаев.
Ещё бы его использовали.

Ja-Ja-Hey-Ho ★★★★
()
Ответ на: комментарий от Deleted

Тут проблема в том, что они разбирают часть пакета шеллом из-под рута. Через eval. Что могло пойти не так?

В лялехе адово нехватает pledge() и нормальной культуры использования непривиллегированных процессов.

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

Что могло пойти не так?

да мне уже не смешно даже.

Но я считаю, проблема в баше - он слишком примитивен для таких вещей. Элементарного искоробочного pattern matching нет. В экосистеме, где вариации строковых параметров «KEY=value» стандарт дефакто - такое непозволительно для шелла.

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

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

Зачем? Пришло время устанавливать обновления.

В 28-й Федоре файл /etc/NetworkManager/dispatcher.d/11-dhclient изначально принадлежит пакету dhcp-client-4.3.6-19.fc28, но теперь пришло обновление пакета - dhcp-client-4.3.6-20.fc28.

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

да, это делается и для центоса и для федоры одной командой «yum update -y dhcp\*» , если тут еще остались паникующие страдальцы

Deleted
()

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

anonymous
()

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

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

Честно говоря, я не вижу проблемы в языке для systemd. Если ты посмотришь на скрипты для гентового openrc или опенбсдшного rc, то ты увидишь, что они по большей части состоят из пяти строк следующего вида:

#!/bin/ksh
#
# $OpenBSD: dhcpd,v 1.3 2018/01/11 19:52:12 rpe Exp $

daemon="/usr/sbin/dhcpd"

. /etc/rc.d/rc.subr

rc_reload=NO

rc_pre() {
	touch /var/db/dhcpd.leases
}

rc_cmd $1

Это отлично переносится на ini стиль.

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

Ну если вспоминать историю лет так 20 назад то и в самом dhcp полно было дырок.
Но конечно «весело получилось»... на eval... даже меня на лоре знатоки «шела» и то мордой тыкали в «небезопасный код»... а тут ынтерпрайз...

anc ★★★★★
()

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

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

И много ли вредоносных DHCP-серверов?

У многих в качестве DHCP-серверов их же собственные роутеры. А не роутеры крякеров.

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

И много ли вредоносных DHCP-серверов?

Звонок жене.
Дорогая ты где?
Еду по садовому кольцу
Будь осторожна, по радио передали что какой-то дурак едет по встречке
Какой-то???? Да их тут сотни!!!

Это к тому что «коробочек» чуть больше чем дофига.

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

И что это меняет для юзера если у него уже настроено подключение к его собственному роутеру хотя бы и по этому же Wi-Fi'ю? Тут хоть тысячу таких вредоносных Wi-Fi подключений организуй - юзер юзает своё надёжное.

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

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

Притаскивает такой юзер на работу «карманный роутер» и фигак...

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

И что это меняет для юзера если у него уже настроено подключение к его собственному роутеру хотя бы и по этому же Wi-Fi'ю? Тут хоть тысячу таких вредоносных Wi-Fi подключений организуй - юзер юзает своё надёжное.

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

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

Вы, видимо, плохо представляете, как работает сеть. Подключившись к маршрутизатору по Wi-Fi, вы лишь установили физическое соединение, никакого IP-адреса ещё нет. Далее ваше устройство отправляет широковещательный DHCP-запрос, и если в сети присутствует ещё один DHCP-сервер кроме вашего, то он вполне может успеть отправить ответ первым.

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

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

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

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

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

Одного достаточно, что бы ботнет посадить. Сидит студентик с ноутом, ему «подарили», профит!

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

конструкции «присваивание» и «вызов подпрограммы» можно на любом (ну, почти) языке записать просто, тут как раз ничего придумывать не надо.

А вот удобные конструкции для обработки переданных структур с именованными параметрами, или парсинг строк, должны быть удобными _некостылями_.

Что касается s-d-unit. Первое, что приходит в голову - порядок вычисления. Там как бы все эти 'Name=MyName' выглядят в декларативном стиле, но многие требуют определенный порядок следования и завязываются на порядок соседних. Это сделано неявно, некрасиво и выглядит как банальное отсутствие проектирования.

Еще, множественное использование shell-строк во всяких Exec*. Я бы предложил сами Unit-ы писать на скриптовом языке, в котором есть возможности shell, но который более высокоуровневый, чем баш. Примерно то, что ты показал для опенбсдшного rc, только это должен быть не классический shell , а улучшенный. Вот на нем надо было сосредоточнить усилия по проектированию. Но понятно, Лёне было не до языка, руки чесались крутить системные вещи, а для конфигов выбрали ini-синтаксис, который ожидаемо оказался узок для такого.

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

Там как бы все эти 'Name=MyName' выглядят в декларативном стиле, но многие требуют определенный порядок следования и завязываются на порядок соседних

«Многие» - это какие? Кроме Exec* ничего в голову и не приходит, а их явно недостаточно для «многие».

И что означает «завязываются на порядок соседних»?

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

публичной вайфай сетью

Это всегда риск. Про это и говорить нечего. Я говорю конкретно про собственный DHCP-сервер юзера. Пусть и через Wi-Fi.

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

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

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

Как я и говорил, вы плохо понимаете, как это всё работает. Изучите матчасть на досуге. Начните с модели OSI.

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

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

Злоумышленный ответ DHCP может заставить скрипт выполнять произвольные команды оболочки с привилегиями root

Т.е. тут конкретно речь о том, что должен быть ответ вредоносного DHCP-сервера, чтобы скрипт начал его обрабатывать. А не так, что без всяких соединений вредоносный пакет по сети пришёл и всё поломал.

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

Вот в ответе saahriktu вы не правы

В чём? При чём здесь DHCP-сервер к ESSID и WPA-ключу, если они вообще на разных уровнях?

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

Именно в этом. «Нет ручек, нет печенек» До дхтп еще добраться надо.

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