в венде есть nap

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

Действительно, это надёжнее =).

Подобный сабжевому скрипт из dhcpcd

# Set the hostname from DHCP data if required

need_hostname()
{
        local hostname=""

        case "$force_hostname" in
        [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|1) ;;
        *) hostname="$(hostname)";;
        esac
        case "$hostname" in
        ""|"(none)"|localhost|localhost.localdomain)
                [ -n "$new_host_name" -o -n "$new_fqdn_name" ];;
        "$old_host_name"|"$old_fqdn_name")
                true;;
        *)
                false;;
        esac
}

set_hostname()
{
        if need_hostname; then
                if [ -n "$new_host_name" ]; then
                        hostname "$new_host_name"
                elif [ -n "$new_fqdn_name" ]; then
                        hostname "$new_fqdn_name"
                fi
        fi
}

if $if_up; then
        set_hostname
fi

Я вижу «$new_host_name» заквоченным, так что ничего страшного происходить не должно, верно?

// c: insurance recese

в венде есть nap

Я вот не сильно разбираюсь в вендах, но разве NAP как-то поможет от подмены DHCP-сервера?

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

Чисто для DHCP ЕМНИП ничего такого нет. Можно решить проблему несколько другим путём - развернуть WPA2 Enterprise поверх ethernet-сети =).

Я вижу «$new_host_name» заквоченным, так что ничего страшного происходить не должно, верно?

По идее да. Но мы ещё не до конца поняли как должна работать эта уязвимость =).

>развернуть WPA2 Enterprise поверх ethernet-сети =)

Люто, бешено запрашиваю подробности.

Если бы такую уязвимость нашёл я, я бы захватил власть над миром.

Можно делать силами свича провайдера. Гугли dhcp snooping.

У нормальных провайдеров это уже лет 5 должно быть включено.

развернуть WPA2 Enterprise поверх ethernet-сети =)

Люто, бешено запрашиваю подробности.

По идее - hostapd на сервере, wpa_supplicant на клиенте. Но сам лично я это настраивал только со стороны клиента.

В супер-мега защищенной OpenBSD этот пакет используется тоже?

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

Утечка сырья «дырки» на фабрике по изготовлению дуршлагов.

Не подскажете, что почитать на тему?

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

Не подскажете, что почитать на тему?

Всякое-разное про IEEE 802.1X, документацию к hostapd на тему driver=wired, документацию к wpa_supplicant на тему опции -D wired. Но повторюсь: сам я такое всё вместе настраивать не пробовал, вполне возможно что оно работает совсем не так как я себе представляю...

802.1x строго пофиг, в какой среде применяться. Однако хз, как это реализовано в линупсе. Видел реализацию .1x «в проводах», на цисковском оборудовании с виндовым RADIUS-сервером. Впечатлился.

Механизм проверки подлинности DHCP-сервера - полная чушь. Как комп может проверить эту подлинность? У него еще нет сетевого адреса, даже спросить не у кого. Если в сети будет левый DHCP, и если он будет отвечать на запросы клиентов быстрее, чем легитимный DHCP, у клиентов БУДУТ левые адреса.

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

NAP - очень хорошо. Он что, позволяет адреса получать без DHCP? Не смешно даже. Не теплое и не мягкое.

А вообще позитивная новость, мне нравится.

802.1x строго пофиг, в какой среде применяться. Однако хз, как это реализовано в линупсе. Видел реализацию .1x «в проводах», на цисковском оборудовании с виндовым RADIUS-сервером. Впечатлился.

Я с этим столкнулся всего один раз, когда настраивал офисный сервер одной организации, которой провайдер интернет доставляет эзернетом с авторизацией 802.1x. С клиентской стороны в линупсе всё ОК - wpa_supplicant завёлся сходу. А вот по поводу сервера - хз. У того провайдера скорее всего за авторизацию и раздачу интернета отвечала какая-нибудь циска.

Если в сети будет левый DHCP, и если он будет отвечать на запросы клиентов быстрее, чем легитимный DHCP, у клиентов БУДУТ левые адреса.

А если умный коммутатор будет фильтровать базар клиентов, решая кому можно отправлять DHCP и кому нельзя, владельцы «левые DHCP» обломаются как бы быстроих сервера не отправляли кривые ответы.

> Механизм проверки подлинности DHCP-сервера - полная чушь. Как комп может проверить эту подлинность? У него еще нет сетевого адреса, даже спросить не у кого.

Не, ну если постараться, то думаю можно разработать dhcp'шную опцию для передачи подписи для стандартных параметров (и даже других опций) прямо в ответах сервера.

> Есть какой-нить механизм проверки подлинности DHCP-сервера?

Оказывается, есть RFC3118. Насколько и где он реализован – хз.

Странно, но никакой функции set_hostname я там не нашел. Только две строчки:

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

Для убунты, в большинстве случаев, достаточно две строчки местами поменять:

if [ -n "$new_host_name" ]; then

и

if [ ! -s /etc/hostname ]; then

Для убунты, в большинстве случаев, достаточно две строчки местами поменять:

Лично я в убунтовском скрипте вообще уязвимости не вижу. В федоровском уязвимость есть, но не remote code execution, а максимум DoS.

Для убунты вообще ничего делать не надо, там $new_host_name заквочен.

Я всё понял!

ISC dhclient did not strip or escape certain shell meta-characters in responses from the dhcp server (like hostname) before passing the responses on to dhclient-script. Depending on the script and OS, this can result in execution of exploit code on the client.

Так что сам по себе dhclient не уязвим, уязвимыми *могут быть* скрипты конкретной ОС или конкретного дистрибутива. Судя по всему, в ubuntu и debian уязвимости нет.

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

Да это понятно. Так, на всякий случай. Вдруг еще что вылезет с обработкой заквоченных строк.

ну а я вот который раз толдычу:

если вы НЕУММЕЕТЕ писать скрипты на bash (а умеете например на Perl или Python или XXX) — то и пишите скрипты именно на том языке на котором умеете

Что курили разработчики? Это же любой ведроидофон можно эксплуатировать так.

Странно, что это заметили лишь сейчас.

> а вот прова сломать было бы ололо.

Дыра в клиенте. Это провы тебя будут ломать направо и налево. Ну и гэбня тоже.

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

HOSTNAME=«vasja_pupkin.com; rm -rf /»

hostname ${HOSTNAME}

> Если бы такую уязвимость нашёл я, я бы захватил власть над миром.

Интересно, как? Для этого не плохо было бы быть не самым последний провайдером, чтобы подключённых к тебе сначала попытаться захватить.

HOSTNAME=«vasja_pupkin.com; rm -rf /»

hostname ${HOSTNAME}

В bash и dash не работает.

HOSTNAME="vasja_pupkin.com; rm -rf /"
hostname ${HOSTNAME}

Не взлетит:

$ foo="bar; echo baz"
$ set -x
$ hostname $foo
+ hostname 'bar;' echo baz

А все потому, что шелл сначала определяет конец команды, а потом уже проводит все expansions и substitutions.

Тут правда есть еще один момент: если противник контролирует dhcp-сервер

Противником может быть провайдер «бесплатного» WiFi и таким образом снабжать всех «Linux-оидов» троянами когда они будут пользоваться его сеткой.

> Противником может быть провайдер «бесплатного» WiFi и таким образом снабжать всех «Linux-оидов» троянами когда они будут пользоваться его сеткой.

Нет никаких троянов тут, самое большее, на что эта фигня способна, это DoS.

> + hostname 'bar;' echo baz

Ну вставь пробел перед ;

> Противником может быть провайдер «бесплатного» WiFi и таким образом снабжать всех «Linux-оидов» троянами когда они будут пользоваться его сеткой.

А это идея! У меня как раз открытая сетка вифи.

Ну вставь пробел перед ;

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

$ foo="bar ; echo baz"
$ set -x
$ hostname $foo
+ hostname bar ';' echo baz

Все равно, когда подставляются переменные, точка с запятой уже не распознается как конец команды.

В генте заквочено. Опять феил.

Я делал cd / && echo.... :)
Я понимаю что делает эта команда, но повторюсь - даже на ляптоповом 320GB харде с мизерной 5400 скоростью ничего страшного не случилось.

при условии если у меня линукс наружу торчит и используется именно dhclient.

у меня статика и внешник :)
плюс фраерволльчик и прочие радости жизни.

И после этого кто-то еще на Си гнать будет с переполнением буферов. Вон на bash даже поле не пахано.

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

Так посоны.Поясните меня что не так HOSTNAME=«vasya.cc.local; ls -l» hostname ${HOSTNAME}

Но оно мне просто пишет что не верный ключ «l» То есть ничего не выполняется.

> Поясните меня что не так

Пояснили уже. http://www.linux.org.ru/jump-message.jsp?msgid=6119723&cid=6121983 http://www.linux.org.ru/jump-message.jsp?msgid=6119723&cid=6122576

Подробности см. в bash(1)

Непонятки

Я правильно понимаю, что для того, чтобы это использовать, в dhclient.conf должно стоять request host-name?

dhcp3 (3.1.3-2ubuntu3.1) lucid-security; urgency=low

* SECURITY UPDATE: arbitrary code execution via crafted hostname - debian/patches/CVE-2011-0997.dpatch: filter strings in client/dhclient.c, common/options.c. - CVE-2011-0997  — Marc Deslauriers <email address hidden> Mon, 11 Apr 2011 08:57:21 -0400