Вышел релиз широко известного сетевого сканера nmap 5.0. По словам самого автора, этот релиз является наиболее важным за последние 12 лет.

Ниже представлен краткий список наиболее интересных улучшений:

• В комплект программ, поставляемых с nmap, добавлена утилита ncat — улучшенная версия старого доброго nc. Среди прочих ее достоинств — работа не только с TCP, но и с UDP, а также встроенная возможность проксирования через HTTP/CONNECT и SOCKS.
• Также в комплект добавлена программа ndiff, позволяющая легко сравнивать результаты различных сканов.
• Проведена большая работа по повышению скорости сканирования портов. В частности, был обновлен и переработан список TCP-портов, сканируемых по умолчанию. Сейчас в нем 1715 портов. А в режиме быстрого сканирования (nmap -F) теперь сканируются не 1300 портов, как раньше, а только 100 наиболее часто используемых.
• В два раза увеличена база сигнатур операционных систем. Теперь она содержит 2003 записи. Также была значительно увеличена база сигнатур приложений — с 4558 до 5512 записей.
• Значительно улучшена работа NSE (Nmap Scripting Engine), расширения, позволяющего использовать простые скрипты для автоматизации различных действий с Nmap. Число скриптов в комплекте увеличено в полтора раза (теперь их 59), добавлены скрипты для симулирования атак, осуществления различных проверок на наличие уязвимостей, подбора паролей через SNMP и POP3, выполнения whois-запросов, определение поражения червем Conficker, проверки наличия открытых SOCKS-прокси и т.д.

По мотивам opennet.ru

>>> Подробности

Автор проекта grsecurity, Brad Spengler, опубликовал эксплойт, использующий очень интересную уязвимость в ядре Linux (драйвер net/tun).

Специфика этой уязвимости состоит в том, что уязвимость отсутствует в исходном коде, но присутствует в бинарном. Как такое возможно? Давайте рассмотрим это на примере. Все начинается с того, что происходит инициализация указателя sk:

struct sock *sk = tun->sk;

Несколькими строками ниже происходит проверка инициализации указателя tun:

if (!tun)
        return POLLERR;

Но! При сборке кода компилятор полагает, что указатель tun уже корректно инициализирован и, оптимизируя код, выкидывает проверку факта инициализации (приведенный выше оператор if). Таким образом, ничто не мешает злоумышленнику заставить ядро обращаться по нулевому адресу. Имеем классическую null pointer dereference vulnerability.

Обнаруженная уязвимость позволяет злоумышленнику обойти ограничения SELinux/AppArmor, вызвать крах ядра либо выполнить произвольный код с рутовыми привилегиями.

Представленный сплойт протестирован на ядрах версий 2.6.30 с SELinux и без, а также на 2.6.18 (RHEL5, собирать с опцией -DRHEL5_SUCKS). Для успешной работы данного сплойта необходимо наличие на машине PulseAudio и подгруженного модуля tun.

Более подробную информацию вы можете прочитать в комментариях к коду эксплойта.

Кстати, эту уязвимость уже активно обсуждает у нас в толксах.

>>> Эксплойт

В программе dhclient (реализация DHCP-клиента от ISC) была обнаружена уязвимость (переполнение буфера при обработке параметра subnet-mask), позволяющая злоумышленнику выполнить на атакуемой машине произвольный код с рутовыми привилегиями.

Для успешного проведения атаки злоумышленнику необходимо внедрить в атакуемую сеть специально модифицированный DHCP-сервер либо захватить контроль над одним из действующих серверов.

Уязвимости подвержены версии dhclient с 2.0 по 4.1. Пользователям рекомендуется срочно обновиться до версий 3.1.2p1, 4.0.1p1 или 4.1.0p1.

Уже вышли исправления для Gentoo и Debian.

>>> Подробности

Поступила информация об обнаружении опасной уязвимости в Firefox 3.5.

Уязвимость имеет тип heap spray, т.е. позволяет записать произвольные данные в область кода процесса за счет неконтролируемого превышения длины строки и выхода ее за пределы динамически распределяемой области памяти. Обусловлена она наличием серьезных ошибок в JavaScript-движке браузера.

Таким образом, при открытии пользователем специально сформированной веб-страницы, возможен отказ в обслуживании (падение браузера) либо исполнение на его машине произвольного кода.

Как сообщается в комментариях в коде эксплойта, он был протестирован на Firefox 3.5. Дополнение от автора новости: Firefox 3.0.11 этот сплойт тоже успешно роняет.

В настоящее время исправления ошибки от производителя отсутствуют, поэтому пользователям рекомендуется воздерживаться от посещения незнакомых страниц и использовать дополнение NoScript, отключающее исполнение JS-кода на сайтах, не подтвержденных пользователем.

>>> Код эксплойта на milw0rm

Сталкивались ли вы когда-нибудь с появлением «левого» DHCP-сервера в сети, большая часть компов которой получает адреса через DHCP? Это может быть сеть вашего провайдера, или администрируемая вами корпоративная сетка... В итоге - падение сети на всех клиентских машинах.

Конечно, есть такие прекрасные вещи, как DHCP snooping на свичах и ebtables на клиентских машинах. Но snooping поддерживают далеко не все свичи, да и сами свичи могут находиться вне подконтрольной вам зоны. А ebtables у каждого клиента настраивать - то еще веселенькое занятие (особенно в отсутствие сети).

Предлагаемая вашему вниманию программа dhcdrop обеспечивает поиск сторонних DHCP-серверов и их подавление путем исчерпания пула IP-адресов (DHCP starvation). Например,

sudo dhcdrop -i eth1 -y -l 00:11:22:33:44:55

проводит «зачистку» с интерфейса eth1, не трогая «легальный» сервер с маком 00:11:22:33:44:55 и снося все живое без лишних вопросов (-y).

Также эта программа может применяться для стресс-тестирования DHCP-серверов.

>>> Подробности

Необходимо создать лекговесный сниффер, способный анализировать заголовки сетевого (IPv6) и канального (TCP, UDP) уровня. (Содержимое канального уровня и дальше вглубь интереса не представляет.)

В случае с IPv4 задача уже решена, однако сейчас моих знаний об IPv6 недостаточно, чтобы портировать это решение под данный протокол.

Собственно о чем прошу:
1. Реализуема ли эта задача средствами сырых сокетов, или нужно использовать pcap? Просто в процессе гугления наткнулся на информацию, что для IPv6 нельзя получить заголовки пакетов из сырых сокетов. Так ли это?
2. Дайте плз ссылки на вменяемые примеры парсинга указанных заголовков из сырых сокетов - если это возможно, если нет - аналогичная просьба про pcap. Отсылки к RFC и ip6.h будут рассматриваться как неинформативные, ибо теория без практики мертва :)

Представители проекта Debian GNU/Linux опубликовали ответ на небезызвестное открытое письмо Ричарда Столлмана, посвящённое возможным проблемам с Mono и C#.

Вердикт - Debian не будет включать Mono и базирующиеся на нем приложения в установку GNOME по умолчанию.

Сейчас в Дебиане есть три метапакета, предоставляющих окружение GNOME в различных комплектациях: gnome-core - минимальная установка GNOME, gnome-desktop - базовая установка, и gnome - полная установка, включая Mono-приложения, такие как tomboy.

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

>>> Подробности

Управляющим советом Ubuntu (Ubuntu Technical Board) опубликована официальная позиция по вопросу включения в дистрибутив программ, требующих для своей работы Mono.

Вердикт - нет объективных причин для исключения Mono или связанных с ним программ из архива пакетов Ubuntu или установочного набора дистрибутива. Так как Mono по умолчанию входит в комплект многих ремиксов дистрибутива и базовой desktop-редакции в частности, зависимость приложения от Mono не может влиять на принятие решения по включению данного приложения в базовую комплектацию дистрибутива.

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

Взято с opennet.ru

>>> Подробности

Как сказано вот в этом интересном документе (http://www.vniiftri.ru/rus/news/91.html), с весны прошлого года Всероссийский Научно-Исследовательский Институт Физико-Технических и Радиотехнических Измерений предоставляет широким массам услуги NTP-серверов, действующих "на базе Государственного эталона времени и частоты".

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

Вот на днях заметил, что все три их сервера stratum 1 работать перестали. Пинговаться - пингуются, и время на них нормальное, в пределах погрешности, а стратум почему-то 16. Естественно, ни один нормальный сервер синхронизироваться по ним не будет.

Вспомогательный же сервер стратума 2 почему-то работает в штатном режиме.

Посему вопрос: кто-нибудь знает что с ними произошло?

Дернула меня нелегкая водрузить Xen на десктопную машину.

После окончания загрузки на dom0 упала сеть. Причем с момента подъема eth0 до запуска xend сеть была, а потом упала. Вскрытие показало, что xend меняет MAC-адрес eth0 на fe:ff:ff:ff:ff:ff.

Далее в дело пошел гугл. Оказалось, что это врожденный косяк реалтековских встроенных сетевух (RTL8111/8168B PCI Express Gigabit Ethernet controller).

Было предложение включить какую-то опцию сетевухи в биосе (что-там про ROM). Она оказалась уже включена. Пробовал выключать, снова включать - не помогает.

Еще было предложение вместо дефолтного в центосе r8169 накатить из elrepo r8168. Накатил, прописал алиасом для eth0 в modprobe.conf - не помогло. Т.е. сеть работает, но только после ручного прописывания настоящего мака.

В конечном счете остановился на компромиссе - в конфиге ксена вместо (network-script network-bridge) выставил (network-script network-route) и vif-script аналогично, а также покапал начальству на мозги на предмет закупки новой сетевухи.

Собсно целей у данного поста две:
1. Сообщить широким массам, что встроенные реалтековские сетевухи - у..бищное г..но.
2. Спросить - может (вдруг) все-таки кто-то знает, как это можно вылечить?

Суть задачи стара как мир: нужно ограничивать/приоретизировать трафик на основании протоколов прикладного уровня.

Насколько я понял из документации по tc, фильтрация по handle <метка> fw хватает отдельные пакеты, а не соединения. Также, как показала практика, l7-filter тоже маркирует только отдельные пакеты. Например, для http он метит только начало ответа сервера (там где заголовки, которые матчатся по регэкспам).

Получается такая картина: для всех пакетов с маркировкой нужно делать CONNMARK --save-mark, а для всех пакетов без маркировки пакета, но с маркировкой соединения - CONNMARK --restore-mark.

Вроде логично. Но гугл выдает кучу манов, в которых таких вещей и близко нет. Вот мне и стало интересно: то ли я чего-то не понял, то ли столько "гениальных" копипаст^Wавторов поразвелось.