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)

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

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

Это ж ентерпрайс. Говнокоды там любят и тщательно охраняют.

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

На параметре с переводом строки он падает, на эксплоите он эксплуатируется.

А потом окажется, что всё это всё равно мусор и на самом деле надо было изначально проверить на допустимые символы [a-z0-9_.] и всё остальное игнорировать и писать огромными красными буквами: «вас хотят взломать!» :)

Собственно, урезанные shell-подобные интерпретаторы так и добиваются эксплойтоустойчивости - либо не обрабатывают всякие закрорючки специальными способами либо вообще говорят - я не уразумею.

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

Соглашусь. Считаю. что данные надо либо передавать как есть, либо фильтровать. Но не портить как попало. Теперь там наложен патч с read -r и слеши перестали съедаться и хз как это ещё аукнется.

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

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

Ты видимо немножко не понял, проблема не в Bash, не в init'е. Проблема в криворуких красношляпых разработчиках, которые используют инструменты не по назначению.

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

Согласен, некорректно написал, имел ввиду бота :)

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

Если в метро действительно ноутбуками пользуются мало

На мцк больше ноутов, там комфотнее. Понятно что процентное отношение относительно не большое, но все-таки типа метро :)

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

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

То-то в леннартоподелии очередной идиотский способ поиметь рута находится на регулярной основе.

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

да, это делается и для центоса и для федоры одной командой rm /etc/NetworkManager/dispatcher.d/*-dhclient

Починил.

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

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

А в чём, собственно, проблема? Приходишь со своим ноутом в кафешку, подключаешься к местному вифи, запускаешь свой уличный DCHP-сервер, собираешь ботнет из красноглазиков красношляпочников попивая смузи, профит.

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

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

Хорошо, какие альтернативы bash юзать можно? Тут проблема не в шелле, а в использовании eval, вообще эту хрень не стоит нигде юзать

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

systemd buffer_overflow.c

Я не про это, а про то, какой шелл заместо bash предлагают тут юзать

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

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

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

Ничего поднимать не нужно, достаточно знать пароль сети, иметь зловредный DHCP-сервер и нужным образом использовать Wi-Fi deauthentication attack.

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

Задача конкретно этого скрипта — это взять все переменные окружения, начинающиеся с «DHCP4_», привести их имена к lowecase, заменить префикс «dhcp4_» на префикс «new_» и затем вызвать с ними в окружении скрипты из каталога /etc/dhcp/dhclient.d/, потому что интерфейс передачи данных из dhcp-ответов у хуков в NetworkManager-е и в dhclient-е отличаются и для совместимости надо преобразовывать имена переменных окружения.

При этом без eval-а ты переписать неопределенный набор переменных окружения не можешь: что там после префикса DHCP4_ — зависит от конкретной инфраструктуры, а список возможных DHCP-опций весьма обширен (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters....) и постоянно меняется, NTP-серверы — это лишь один из примеров.

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

Вообще должно быть sane defaults

ну что я могу на это сказать? только процитировать классика: «And all the children are insane»

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

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

Задача «разбить строку на токены и вызвать шелл-скрипт в этом окружении» элементарно решается на C без привлечения ШЕЛЛ СКРИПТА С eval'ОМ ПОД РУТОМ. Ну серьезно, что за ерунда.

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

надо же еще процы пофиксить
а то в «крузис» не поиграть будет

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

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

Когда полный список имен переменных окружения заранее неизвестен, то, к сожалению, нужен.

А в интерпретируемых языках нельзя списки произвольной длины обрабатывать?

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

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

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

Тут проблема не в том, как их получить (declare или env в помощь), а как потом переменные окружения задать.

new_${SUFFIX}=${DHCP4_VARIBLE}
знаешь ли, не сработает.

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

Ок с export вариант сработает

export "new_${suffix}=${variable}"
anonymous
()
Ответ на: комментарий от Gargamel

Никакой. Очнись, на дворе XXI век уже.

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

Спасибо за идею, передал автору оригинально скрипта, сидит, учится.

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

спасибо, не зря подписался на тему

${!prefix*} - так и знал, что что-то такое должно быть. Явное пренебрежение изучением баша как у меня так и автора дырявого скрипта

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

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

Звучит как 4.2. Приведи пример.

Но понятно, Лёне было не до языка, руки чесались крутить системные вещи, а для конфигов выбрали ini-синтаксис, который ожидаемо оказался узок для такого.

В systemd изначально декларировалось, что юниты не должны быть Тьюринг-полными. Правильно это или нет — вопрос отдельный, но ты сейчас точно не прав.

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

В systemd изначально декларировалось, что юниты не должны быть Тьюринг-полными. Правильно это или нет — вопрос отдельный, но ты сейчас точно не прав.

Тьюринг-полнота не имеет отношения к вопросу о синтаксисе. Например, в Tcl синтаксис и семантика отделены. Можно инстанциировать интерпретатор, который понимает весь синтаксис, но не имеет ни одной встроенной команды. Если мы добавим туда ограниченный набор команд, то получим тьюринг-неполный, но при этом Tcl-совместимый язык. Можно им парсить конфиги. И в то же время получившийся язык достаточно гибкий: можно использовать списки, вложенные конструкции и т.п.

Уж явно лучше убогого синтаксиса ini из Windows 3.11.

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

Я не про это, а про то, какой шелл заместо bash предлагают тут юзать

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

Deleted
()

В центоси фикс уже давно есть:


12:dhclient-4.2.5-68.el7.centos.1.x86_64 installed
* Tue May 15 15:00:00 2018 CentOS Sources <bugs@centos.org> - 4.2.5-68.el7.centos.1
- Roll in CentOS Branding

* Tue Apr 24 15:00:00 2018 Pavel Zhukov <pzhukov@redhat.com> - 12:4.2.5-68.1
- Resolves: #1570898 - Fix CVE-2018-1111: Do not parse backslash as escape character

* Wed Feb 28 15:00:00 2018 Pavel Zhukov <pzhukov@redhat.com> - 12:4.2.5-68
- Resolves: #1549999 - CVE-2018-5733  Avoid buffer overflow reference counter

* Wed Feb 28 15:00:00 2018 Pavel Zhukov <pzhukov@redhat.com> - 12:4.2.5-67
- Resolves #1549998 :CVE-2018-5732  Avoid buffer overflow in options parser

* Thu Dec  7 15:00:00 2017 Pavel Zhukov <pzhukov@redhat.com> - 12:4.2.5-65
- Resolves: #1519363 - omapi: Close orphaned sockets.

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

заранее неизвестен, то, к сожалению, нужен

здесь-то? с какого? prefix известен... legolegs весь вопрос осветил чуть менее чем полностью

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

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

Дело в том, что bash вообще предлагают убить нахрен

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