Критическая уязвимость в dhclient (удалённый root)

Вот это дырища...

ООО! Пока своего провайдера ломать )) Жалко, что толку мало и, что там работаю ((

РЕШЕТО

*пересилил сон и полез по ssh на сервер проверить апдейты*

Это даже не решето, это что-то совершенно невообразимое.

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

так ведь проблема то на клиентах, а не на сервере.
клиентов dhcp надо обновлять

Хм... В Ubuntu 10.04 в /sbin/dhclient-script (dhcp3-client 3.1.3-2ubuntu3) функции set_hostname нет, единственное упоминание new_host_name:

        if [ -n "$new_host_name" ]; then
            if [ ! -s /etc/hostname ]; then
                hostname "$new_host_name"
            fi
        fi

    if [ -n "${new_host_name}" ] && need_hostname; then
        hostname ${new_host_name} || echo "See -nc option in dhclient(8) man page."
    fi

А, всё, я понял как уязвимость работает. Она есть =).

Она есть =).

Но «работает» только если разрешено получение имени хоста по DHCP, что обычно не так.

Как ты прова-то собрался ломать? :) Наооборот - это он тебя поиметь может :) Уязвимость на клиенте. Ололо.

а малоли у них гденить на серваках по дхцп ип получается :)

Вот обязательно нужно, чтоб кто-нибудь подключенный с ним в один свич у провайдера (обычный неуправляемый, конечно) поднял свой dhcp-server и рассылал какие-надо пакеты. А у него при этом eth0 не был прописан в static.

В ISP вообще дебилы работают и никакой DMZ не держат для таких кулхацкиров доморощенных :)

спасибо за комплимент :)
как в адрес ISP, так и в мой :)

+!

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

Для перлоедов: обработка регэкспами к парсингу не относится.

В дебиановском dhclient-script $new_host_name заквочен. Так что далеко не везде уязвимо.

> IRL уязвимости нет?

В убунтовском варианте нет. А в федоровском таки есть.

dhcpcd - и ваши волосы станут мягкими и шелковистыми. :-)

IRL уязвимости нет?

В убунтовском варианте нет. А в федоровском таки есть.

Значит я не понял как должна работать эта уязвимость. Можно пример? Что-то типа такого:

EXPLOIT="Что тут должно быть?"
hostname ${EXPLOIT}

EXPLOIT=«`ls -la`»

в слаке вот:

  current_hostname=`hostname`
  if [ x$current_hostname = x ] || \
     [ x$current_hostname = "x(none)" ] || \
     [ x$current_hostname = xlocalhost ] || \
     [ x$current_hostname = x$old_host_name ]; then
    if [ x$new_host_name != x$old_host_name ]; then
      hostname "$new_host_name"
    fi
  fi

впрочем я dhcpcd юзаю в основном.

EXPLOIT=«`ls -la`»

Не работает.

Сдается мне, я поторопился. Подумав, я, пожалуй, не вижу возможности remote code execution даже в федоровском варианте.

Присоединяюсь к вашему желанию увидеть работающий эксплойт. :)

> EXPLOIT=«`ls -la`»

Не взлетит. Parameter expansion и command substitution происходят на одном и том же шаге, поэтому вложенно не работают. Как мне кажется на данный момент, самое большее, что из этого можно выжать, это передать дополнительные параметры для hostname.

Может быть можно добиться DoS'а, если передать какой-нибудь -F <имя-файла-блокирующегося-при-чтении>.

$ EXPLOIT=«`touch /tmp/123.file`»
$ hostname ${EXPLOIT}localhost.localdomain
$ ls -la /tmp/123.file
-rw-r--r-- 1 username users 0 Apr 7 08:22 /tmp/123.file

$ EXPLOIT="`touch /tmp/123.file`"
$ hostname ${EXPLOIT}localhost.localdomain
$ ls -la /tmp/123.file
-rw-r--r-- 1 username users 0 Apr 7 08:22 /tmp/123.file

Неа, не то. В этом случае touch выполняется при присвоении EXPLOIT=, а не при выполнении hostname.

В данном случае touch у вас выполняется в первой строке, а не во второй. :)

Попробуйте EXPLOIT='`touch /tmp/123.file`'

форматирование съехало во 2-й строке

А кто вообще им пользуется ?

EXPLOIT=«Что тут должно быть?»

hostname ${EXPLOIT}

EXPLOIT='/etc/*'

Гыгы.. Сурово.
Вот не нравился мне dhclient.. dhcpcd лучше :)

EXPLOIT=«Что тут должно быть?»

hostname ${EXPLOIT}

EXPLOIT='/etc/*'

Вот это уже интереснее. Но всё равно это не remote code execution, которое заявлено в новости.

да, не remote code execution

> EXPLOIT='/etc/*'

И что это даст?

EXPLOIT='/etc/*'

И что это даст?

DoS например. Попробуй ради интереса:

echo */*/*/*/*/*/*/*/*/*/*/*/*

> Вот не нравился мне dhclient.. dhcpcd лучше :)

dhclient зато более гибок, именно из-за dhclient-script.

А, ну да, это вариант. Правда это будет работать, опять же, только в тех дистрибутах, где $new_host_name незаквочен.

И? Ничего страшного не происходит.

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

Ничего страшного не происходит.

Уверен?

> просто выдав невменяемый айпишнег какой-нибудь.

Ну или там путь, или неймсервер, и так далее.

ы/путь/маршрут/ естественно

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

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

Вот, кстати, да. Есть какой-нить механизм проверки подлинности DHCP-сервера? Ну, чтоб убедиться, что это именно сервер провайдера, а не сосед Вася WAN и LAN на роутере местами перепутал?

> Вот, кстати, да. Есть какой-нить механизм проверки подлинности DHCP-сервера? Ну, чтоб убедиться, что это именно сервер провайдера, а не сосед Вася WAN и LAN на роутере местами перепутал?

Насколько я понимаю, нет. Наверное можно придумать какое-нибудь расширение для dhcp с цифровыми подписями, но, думаю, это будет нетривиально, учитывая существование dhcp-релеев, которые могут модифицировать пакеты по пути.

Ну только что проверил.

есть. Называется IPv6+IPSec

Ничего страшного не происходит.

Уверен?

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

echo /*/*/*/*/*/*/*/*/*/*/*/*/*