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 ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

saahriktu ★★★★★ ()

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

anonymous ()

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

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

Честно говоря, я не вижу проблемы в языке для 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 ★★★★★ ()
Ответ на: комментарий от superuser

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

saahriktu ★★★★★ ()