Дыры есть, их не может не быть ;)
В течение второй половины января новостные сайты и газеты, в том числе и не сетевой тематики, пестрили сообщениями об недавно обнаруженных "ужасных" дырах в DNS-сервере BIND. Якобы хакеры, воспользовавшись этими ошибками в BIND способны чуть ли не полностью парализовать работу всего Интернета. "СР" как изданию специализированному, естественно, следует как-то отреагировать на это событие. Но как вы могли заметить, хотя бы бегло пролистав этот номер, в новостях ничего такого "устрашающе-панического" нет. Почему? Посмотрите на заголовок этого материала :) С первых номеров мы более-менее регулярно публикуем под таким заголовком обзоры дыр в сетевом ПО и железе, и смею вас уверить — видали мы дыры и пострашнее, и пошире, и поглубже :) Каждый месяц участники листа рассылки BUGTRAQ отлавливают дюжину разнокалиберных "блох", и BIND, прошу заметить, далеко не самое редковстречаемое имя в списках отличившихся. Так что, господа хорошие, ничего особенного не произошло, вот они — эти "страшные" дыры:дыра в ISC Bind 8 — Transaction Signatures Buffer Overflow
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 8.2.2 p7, ISC BIND 8.2.2 p6, ISC BIND 8.2.2 p5
для Trustix Trustix Secure Linux 1.1, Trustix Trustix Secure Linux 1.0, S.u.S.E. Linux 6.4ppc, S.u.S.E. Linux 6.4alpha, S.u.S.E. Linux 6.4, S.u.S.E. Linux 6.3 alpha, S.u.S.E. Linux 6.3, S.u.S.E. Linux 6.2, S.u.S.E. Linux 6.1 alpha, S.u.S.E. Linux 6.1, S.u.S.E. Linux 6.0, RedHat Linux 7.0J sparc, RedHat Linux 7.0J i386, RedHat Linux 7.0J alpha, RedHat Linux 7.0 sparc, RedHat Linux 7.0 i386, RedHat Linux 7.0 alpha, RedHat Linux 6.2E sparc, RedHat Linux 6.2E i386, RedHat Linux 6.2E alpha, RedHat Linux 6.2 sparc, RedHat Linux 6.2 i386, RedHat Linux 6.2 alpha, RedHat Linux 6.1 sparc, RedHat Linux 6.1 i386, RedHat Linux 6.1 alpha, RedHat Linux 6.0 sparc, RedHat Linux 6.0 i386, RedHat Linux 6.0 alpha, RedHat Linux 5.2 sparc, RedHat Linux 5.2 i386, RedHat Linux 5.2 alpha, Mandrake Soft Linux Mandrake 7.2, MandrakeSoft Linux Mandrake 7.1, MandrakeSoft Linux Mandrake 7.0, MandrakeSoft Linux Mand rake 6.1, MandrakeSoft Linux Mandrake 6.0, IBM AIX 4.3.3, IBM AIX 4.3.2, IBM AIX 4.3.1, IBM AIX 4.3, Debian Linux 2.3 sparc, Debian Linux 2.3 powerpc, Debian Linux 2.3 arm, Debian Linux 2.3 alpha, Debian Linux 2.3 68k, Debian Linux 2.3, Debian Linux 2.2 sparc, Debian Linux 2.2 powerpc, Debian Linux 2.2 arm, Debian Linux 2.2 alpha, Debian Linux 2.2 68k, Debian Linux 2.2, Connectiva Linux 5.1, Connectiva Linux 5.0, Connectiva Linux 4.2, Connectiva Linux 4.1, Connectiva Linux 4.0es, Connectiva Linux 4.0, Caldera eServer 2.3, Caldera eDesktop 2.4, Caldera OpenLinux Desktop 2.3
— ISC BIND 8.2.2 p4, ISC BIND 8.2.2 p3, ISC BIND 8.2.2 p2, ISC BIND 8.2.2 p1, ISC BIND 8.2.2, ISC BIND 8.2.1, ISC BIND 8.2
для Slackware Linux 4.0, RedHat Linux 6.1 i386, RedHat Linux 6.0 i386, RedHat Linux 5.2 i386, RedHat Linux 5.1, Standard & Poors ComStock 4.2.4, RedHat Linux 5.0, RedHat Linux 4.2, RedHat Linux 4.1, RedHat Linux 4.0, IBM AIX 4.3.2, IBM AIX 4.3.1, IBM AIX 4.3, Caldera OpenLinux 2.2, Caldera OpenLinux 1.3
Неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
Программа BIND (Berkley Internet Name Domain) является самым популярным сервером доменных имен — она установлена на 90 процентов обслуживающих систему имен Интернета (DNS) компьютеров. Версии BIND 8.2 и выше содержат баг — "single byte stack overflow", который может использоваться для удаленной атаки.
Дыра проявляется, когда BIND принимает запросы по UDP. Когда запрос принят, он читается из дейтограммы и предается в локальный буфер, где обрабатывается. Размер данного буфера — 512 байт, что является максимальным количеством информации, которую можно переслать в одной UDP-дейтограмме.
При отсылке запроса BIND использует этот буфер для создания запроса. Когда BIND обрабатывает запрос, он добавляет данные к DNS-ответу (в локальном буфере).
При включении в запрос сигнатуры транзакции, BIND пропускает нормальную обработку запроса и пытается проверить сигнатуру. Если сигнатура неправильная, то TSIG запрос добавляется в память, туда, где находился конец сообщения. К сожалению, BIND не может нормально обработать сообщение, т.к. сообщение находится частично в буфере. В результате TSIG-ответ выходит за рамки буфера и частично накладывается на стек параметров вызываемой функции. TSIG-отзыв состоит из фиксированных значений, имеющих нулевые байты. Если младший байт базового указателя в стеке параметров изменен, это приводит к получению атакующим контроля над стеком параметров вызываемой функции. Если записать в стеке в поле адреса возврата из функции адрес шелла, тогда мы входим в шелл с правами named.
На данный момент не существует эксплойта, но не стоит расслабляться.
ICS настоятельно рекомендует обновить BIND до версии 9.1.0. А вот собственно и обновления.
ISC BIND 8.2.2 p7: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p6: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p5: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p4: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p3: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p1:ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.1: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
дыра в ISC Bind 8 — Transaction Signatures
Heap Overflow
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 8.2.3 Beta, ISC BIND 8.2.2 p7, ISC BIND 8.2.2 p6, ISC BIND 8.2.2 p5, ISC BIND 8.2.2 p4, ISC BIND 8.2.2 p3, ISC BIND 8.2.2 p2, ISC BIND 8.2.2 p1, ISC BIND 8.2.2, ISC BIND 8.2.1, ISC BIND 8.2
неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
Дыра проявляется, когда BIND принимает запросы по TCP. Когда запрос принят, он читается из TCP-потока в буффер, выделенный функцией malloc(). При отсылке запроса, BIND использует данный буфер для создания ответа. Когда BIND обработал запрос, он добавляет данные к DNS-ответу (в буфер, выделенный функцией malloc()).
При включении в запрос сигнатуры транзакции, BIND пропускает нормальную обработку запроса и пытается проверить сигнатуру. Если сигнатура неправильная, то TSIG-запрос добавляется в память, туда, где находился конец сообщения. К сожалению, BIND не может нормально обработать сообщение, т.к. сообщение находится частично в буфере. В результате TSIG-ответ записывается за пределами выделенной памяти.
Переполненный буфер находится в в регионах "bss" или "heap" памяти программы, и в результате не возможно атаковать таким методом, как в примере с переполнением стека. В дополнение, эта часть памяти не является исполняемой, поэтому адрес шелла должен помещаться в стек.
Наиболее приятный способ атаки — повреждение участков памяти, выделенных функцией malloc(), путем вызова функции free(). В результате чего в память записываются данные атакующего. Атакующий, к примеру, может записать в стек адрес шелла, находящегося в исполняемом участке памяти (сегмент кода программы). Когда функция отработала, в стеке уже другой адрес возврата и, соответственно, мы вылетаем в шелл с правами named (в большинстве случаев это root).
Эксплойта пока еще нет, но стоит иметь в виду что он может появиться ;)
ICS снова рекомендует обновить BIND. URL'ы в студию:
ISC BIND 8.2.3 Beta: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p7: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p6: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p5: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p4: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p3: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p1: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.1: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC Bind 4: Переполнение буфера в функции nslookupComplain()
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 4.9.7-T1B, ISC BIND 4.9.7, ISC BIND 4.9.6, ISC BIND 4.9.5P1, ISC BIND 4.9.5, ISC BIND 4.9.4, ISC BIND 4.9.3, ISC BIND 4.9.
Неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
В BIND версии 4 есть дыра (переполнение стека), приводящая к получению root'a удаленно.
При приеме запроса на разрешение имени хоста первым делом проверяются файлы локальных зон и кэш на совпадение с запрашиваемым адресом/именем хоста. Если имя хоста не ресолвится через локальный DNS, BIND пробует опросить сервера, которые дали бы ответ на данный запрос. При получении NS записи, BIND вызывает функцию nslookup(), для получения IP-адреса данного DNS-сервера. Функция nslookup() проверяет на правильность IP-адрес, если адрес неправильный (т.е. 0.0.0.0, 255.255.255.255 или мультикаст-адрес), вызывается функция nslookupComplain() для фиксирования данной ошибки в syslog'е.
Переполнение буфера происходит в функции nslookupCompalin(), при генерации сообщения о ошибке. nslookup-Compalin() использует sprintf() для создания строки, оканчивающейся машинным нулем — '\0'. Эта строка не должна превышать 999 байт и является локальной переменной. Если строка с именем хоста DNS превысит допустимую длину, то все что более 999 байт будет записано в стек nslookupCompalin(). В результате можно изменить адрес возврата из функции на адрес шелла, и — опаньки :).
Одно "но" — атакующий может использовать в запросе только те символы, которые используются в Интернет-именах, а из этого, согласитесь, создать адрес возврата нереально.
Солюшном в данном случае будет обновление BIND до версии 9.1.0.
ISC Bind 4: Некорректный формат строки в nslookupComplain()
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 4.9.7-T1B, ISC BIND 4.9.7, ISC BIND 4.9.6, ISC BIND 4.9.5P1, ISC BIND 4.9.5, ISC BIND 4.9.4, ISC BIND 4.9.3, ISC BIND 4.9.
Неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
Переполнение буфера происходит в функции nslookupCompalin() (что это за функция описано в предыдущей "дыре"), что позволяет атакующему преписывать случайные регионы памяти случайными значениями. Эта строка попадает в syslog() и содержит хитрый запрос (к примеру имя хоста) в качестве аргумента. В некоторых случаях hostname не указывается, и все это передается в *printf(), который используется в syslog().
Если атакующий подберет строку, то случайные регионы памяти будут перезаписаны. К примеру, атакующий может переписать адрес возврата из подпрограммы на адрес шелла. А в результате получить права рута.
Для реализации такой атаки вам потребуется собственный домен (в смысле зона ответственности DNS) и, по всей видимости, более чем один DNS-сервер.
Внимание! Атакующий может использовать в запросе только те символы, которые используются в Интернет-именах, а из этого, согласитесь, создать адрес возврата нереально.
В данном случае ICS рекомендует обновить ваш BIND до версии 9.1.0
DoS дыра в Netscape Enterprise Server при использовании
Web Publishing
Тип: локальная и удаленная.
Опубликована 25 января 2001.
Дополнена 25 января 2001.
Уязвимый продукт:
— Netscape Enterprise Server 3.0.
Netscape Enterprise Server — веб-сервер, который используется для крупномасштабных веб-сайтов. Web Publishing устанавливается по умолчанию. Данная директория доступна локальным и удаленным пользователям без какой-либо аутентификации.
Данная дыра функциональна, если работает Web Publishing. Если пользователь подключается к серверу и посылает команду 'REVLOG / HTTP/1.0', сервер падает. Эту команду необходимо повторить несколько раз, что бы достичь желаемого результата. Только перезапуск сервера возвращает его к нормальному функционированию.
Солюшном в данном случае будет отключить обработку REVLOG-запроса, а лучше — сам Web Publishing.
Дыра с обнаружением 'Index' в Netscape Enterprise Server
Тип: локальная и удаленная.
Опубликована 24 января 2001.
Дополнена 24 января 2001.
Уязвимые продукты:
— Netscape Enterprise Server 4.0, Netscape Enterprise Server 3.0
Снова возвращаемся к Web Publishing.
Netscape Enterprise Server со включенным Web Publishing позволяет показывать список каталогов на данном сервере. Если пользователь соединяется через telnet к серверу и посылает комманду 'INDEX / HTTP/1.0', то в результате выдается список каталогов.
Решение проблемы — отключение Web Publishing или обработки INDEX-запроса.
дыра в Wu-Ftpd — некорректный формат строки и мени хоста
Тип: локальная и удаленная.
Опубликована 23 января 2001.
Дополнена 25 января 2001.
Уязвимые продукты:
— Washington University wu-ftpd 2.6, 2.5, 2.4.2academ [BETA1-15], 2.4.2academ [BETA-18], 2.4.2 VR17, 2.4.2 VR16, 2.4.2 (beta 18) VR9, 2.4.2 (beta 18) VR8, 2.4.2 (beta 18) VR7, 2.4.2 (beta 18) VR6, 2.4.2 (beta 18) VR5, 2.4.2 (beta 18) VR4, 2.4.2 (beta 18) VR15, 2.4.2 (beta 18) VR14, 2.4.2 (beta 18) VR13, 2.4.2 (beta 18) VR12, 2.4.2 (beta 18) VR11, 2.4.2 (beta 18) VR10, wu-ftpd 2.4.1.
Wu-ftpd — широкоиспользуемый ftp-сервер для *NIX-систем.
Когда Wu-ftpd запущен в режиме отладки (т. е. запущен через inetd с опциями -d или -v), то возможна атака на данный сервер с возможностью использования некорректных строк. Когда Wu-ftpd находится в режиме отладки, он ведет лог команд пользователя через syslog() с меткой 'DEBUG'. При пассивной передаче файла, вызванной пользователем (реальным или анонимным), в лог записывается строка вида:
PASV port X assigned to HOSTNAME
Строка, содержащая данное сообщение, собирается перед вызовом syslog(). Значение HOSTNAME ресолвится сервером. Данная строка передается в syslog() как форматированная строка. В результате можно передать строку несоответствующего типа.
Также неизвестно в каких версиях Wu-ftpd режим отладки включен по умолчанию.
Ниже приведен пример эксплойта, демонстрирующего данную дыру.
$grep 127.0.0.1 /etc/hosts
127.0.0.1 %x%x%x%x%x%x%x%x%x%x
$ grep ftpd /etc/inetd.conf
ftp stream tcp nowait root /usr/sbin/tcpd /tmp/wuftpd-2.6.0/src/ftpd -v
$ ncftpget -F 127.0.0.1 /tmp /usr/lib/ld.so
$ tail /var/log/syslog.debug
Jan 24 14:17:01 xxx ftpd[30912]: PASV port 47479 assigned to 80862b0806487eb9778084da87bffff16c9640151020bfffe108401c9004 [127.0.0.1]
..<поскипано>..
По данному поводу Debian выпустила релиз и diff-файлы,которые исправляют данную дыру.
Washington University wu-ftpd 2.6:Debian upgrade 2.2 i386 wu-ftpd_2.6.0-5.2.1_i386.deb
http://security.debian.org/dists/stable/updates/main/binary-i386/wu-ftpd_2.6.0-5.2.1_i386.deb
уклонение от фильтрации пакетов в ipfw для FreeBSD
Тип: локальная и удаленная.
Опубликована 23 января 2001.
Дополнена 25 января 2001.
Уязвимые продукты:
— FreeBSD 4.2, FreeBSD 4.1.1, FreeBSD 4.1, FreeBSD 4.0 alpha, FreeBSD 4.0, FreeBSD 3.5.1, FreeBSD 3.5, FreeBSD 3.4, FreeBSD 3.3, FreeBSD 3.1, FreeBSD 3.0.
Неуязвимый продукт:
— FreeBSD 5.0.
FreeBSD, как и множество других современных систем, имеет подсистему фильтрации пакетов, встроенную в ядро. Дыра в данной системе позволяет атакующему проскакивать через правила фильтрации. Это связано с интерпретацией флага ECE в заголовке TCP-пакета. ECE-флаг — эксперементальное расширение TCP и часть резервных опций TCP.
Когда фильтр пакетов анализирует TCP-пакет, имеющий установленный ECE-флаг, он интерпретирует его как часть уже установленного TCP-соединения и пропускает его.
Атакующий, использующий данную дыру может перехитрить файрвольные правила. Пакеты, сконструированные с установленным ECE-флагом, проходят через файрвол.
Эксплойт выполняющий эти действия представлен Plathond <jacques4i@yahoo. com>и находится по адресу:
http:/securityfocus.com/data/vulnerabilities/exploits/ecepass.tgz
По данному поводу FreeBSD выпустила ряд патчей:
FreeBSD 4.2: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 4.1.1: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 4.1: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 4.0: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 3.5.1: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.5: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.4: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.3: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.1: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.0: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
Ghost//Necrosoft
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 8.2.2 p7, ISC BIND 8.2.2 p6, ISC BIND 8.2.2 p5
для Trustix Trustix Secure Linux 1.1, Trustix Trustix Secure Linux 1.0, S.u.S.E. Linux 6.4ppc, S.u.S.E. Linux 6.4alpha, S.u.S.E. Linux 6.4, S.u.S.E. Linux 6.3 alpha, S.u.S.E. Linux 6.3, S.u.S.E. Linux 6.2, S.u.S.E. Linux 6.1 alpha, S.u.S.E. Linux 6.1, S.u.S.E. Linux 6.0, RedHat Linux 7.0J sparc, RedHat Linux 7.0J i386, RedHat Linux 7.0J alpha, RedHat Linux 7.0 sparc, RedHat Linux 7.0 i386, RedHat Linux 7.0 alpha, RedHat Linux 6.2E sparc, RedHat Linux 6.2E i386, RedHat Linux 6.2E alpha, RedHat Linux 6.2 sparc, RedHat Linux 6.2 i386, RedHat Linux 6.2 alpha, RedHat Linux 6.1 sparc, RedHat Linux 6.1 i386, RedHat Linux 6.1 alpha, RedHat Linux 6.0 sparc, RedHat Linux 6.0 i386, RedHat Linux 6.0 alpha, RedHat Linux 5.2 sparc, RedHat Linux 5.2 i386, RedHat Linux 5.2 alpha, Mandrake Soft Linux Mandrake 7.2, MandrakeSoft Linux Mandrake 7.1, MandrakeSoft Linux Mandrake 7.0, MandrakeSoft Linux Mand rake 6.1, MandrakeSoft Linux Mandrake 6.0, IBM AIX 4.3.3, IBM AIX 4.3.2, IBM AIX 4.3.1, IBM AIX 4.3, Debian Linux 2.3 sparc, Debian Linux 2.3 powerpc, Debian Linux 2.3 arm, Debian Linux 2.3 alpha, Debian Linux 2.3 68k, Debian Linux 2.3, Debian Linux 2.2 sparc, Debian Linux 2.2 powerpc, Debian Linux 2.2 arm, Debian Linux 2.2 alpha, Debian Linux 2.2 68k, Debian Linux 2.2, Connectiva Linux 5.1, Connectiva Linux 5.0, Connectiva Linux 4.2, Connectiva Linux 4.1, Connectiva Linux 4.0es, Connectiva Linux 4.0, Caldera eServer 2.3, Caldera eDesktop 2.4, Caldera OpenLinux Desktop 2.3
— ISC BIND 8.2.2 p4, ISC BIND 8.2.2 p3, ISC BIND 8.2.2 p2, ISC BIND 8.2.2 p1, ISC BIND 8.2.2, ISC BIND 8.2.1, ISC BIND 8.2
для Slackware Linux 4.0, RedHat Linux 6.1 i386, RedHat Linux 6.0 i386, RedHat Linux 5.2 i386, RedHat Linux 5.1, Standard & Poors ComStock 4.2.4, RedHat Linux 5.0, RedHat Linux 4.2, RedHat Linux 4.1, RedHat Linux 4.0, IBM AIX 4.3.2, IBM AIX 4.3.1, IBM AIX 4.3, Caldera OpenLinux 2.2, Caldera OpenLinux 1.3
Неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
Программа BIND (Berkley Internet Name Domain) является самым популярным сервером доменных имен — она установлена на 90 процентов обслуживающих систему имен Интернета (DNS) компьютеров. Версии BIND 8.2 и выше содержат баг — "single byte stack overflow", который может использоваться для удаленной атаки.
Дыра проявляется, когда BIND принимает запросы по UDP. Когда запрос принят, он читается из дейтограммы и предается в локальный буфер, где обрабатывается. Размер данного буфера — 512 байт, что является максимальным количеством информации, которую можно переслать в одной UDP-дейтограмме.
При отсылке запроса BIND использует этот буфер для создания запроса. Когда BIND обрабатывает запрос, он добавляет данные к DNS-ответу (в локальном буфере).
При включении в запрос сигнатуры транзакции, BIND пропускает нормальную обработку запроса и пытается проверить сигнатуру. Если сигнатура неправильная, то TSIG запрос добавляется в память, туда, где находился конец сообщения. К сожалению, BIND не может нормально обработать сообщение, т.к. сообщение находится частично в буфере. В результате TSIG-ответ выходит за рамки буфера и частично накладывается на стек параметров вызываемой функции. TSIG-отзыв состоит из фиксированных значений, имеющих нулевые байты. Если младший байт базового указателя в стеке параметров изменен, это приводит к получению атакующим контроля над стеком параметров вызываемой функции. Если записать в стеке в поле адреса возврата из функции адрес шелла, тогда мы входим в шелл с правами named.
На данный момент не существует эксплойта, но не стоит расслабляться.
ICS настоятельно рекомендует обновить BIND до версии 9.1.0. А вот собственно и обновления.
ISC BIND 8.2.2 p7: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p6: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p5: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p4: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p3: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p1:ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.1: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
дыра в ISC Bind 8 — Transaction Signatures
Heap Overflow
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 8.2.3 Beta, ISC BIND 8.2.2 p7, ISC BIND 8.2.2 p6, ISC BIND 8.2.2 p5, ISC BIND 8.2.2 p4, ISC BIND 8.2.2 p3, ISC BIND 8.2.2 p2, ISC BIND 8.2.2 p1, ISC BIND 8.2.2, ISC BIND 8.2.1, ISC BIND 8.2
неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
Дыра проявляется, когда BIND принимает запросы по TCP. Когда запрос принят, он читается из TCP-потока в буффер, выделенный функцией malloc(). При отсылке запроса, BIND использует данный буфер для создания ответа. Когда BIND обработал запрос, он добавляет данные к DNS-ответу (в буфер, выделенный функцией malloc()).
При включении в запрос сигнатуры транзакции, BIND пропускает нормальную обработку запроса и пытается проверить сигнатуру. Если сигнатура неправильная, то TSIG-запрос добавляется в память, туда, где находился конец сообщения. К сожалению, BIND не может нормально обработать сообщение, т.к. сообщение находится частично в буфере. В результате TSIG-ответ записывается за пределами выделенной памяти.
Переполненный буфер находится в в регионах "bss" или "heap" памяти программы, и в результате не возможно атаковать таким методом, как в примере с переполнением стека. В дополнение, эта часть памяти не является исполняемой, поэтому адрес шелла должен помещаться в стек.
Наиболее приятный способ атаки — повреждение участков памяти, выделенных функцией malloc(), путем вызова функции free(). В результате чего в память записываются данные атакующего. Атакующий, к примеру, может записать в стек адрес шелла, находящегося в исполняемом участке памяти (сегмент кода программы). Когда функция отработала, в стеке уже другой адрес возврата и, соответственно, мы вылетаем в шелл с правами named (в большинстве случаев это root).
Эксплойта пока еще нет, но стоит иметь в виду что он может появиться ;)
ICS снова рекомендует обновить BIND. URL'ы в студию:
ISC BIND 8.2.3 Beta: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p7: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p6: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p5: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p4: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p3: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2 p1: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2.1: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC BIND 8.2: ISC upgrade bind-9.1.0.tar.gz
ftp://ftp.isc.org/isc/bind9/9.1.0/bind-9.1.0.tar.gz
ISC Bind 4: Переполнение буфера в функции nslookupComplain()
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 4.9.7-T1B, ISC BIND 4.9.7, ISC BIND 4.9.6, ISC BIND 4.9.5P1, ISC BIND 4.9.5, ISC BIND 4.9.4, ISC BIND 4.9.3, ISC BIND 4.9.
Неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
В BIND версии 4 есть дыра (переполнение стека), приводящая к получению root'a удаленно.
При приеме запроса на разрешение имени хоста первым делом проверяются файлы локальных зон и кэш на совпадение с запрашиваемым адресом/именем хоста. Если имя хоста не ресолвится через локальный DNS, BIND пробует опросить сервера, которые дали бы ответ на данный запрос. При получении NS записи, BIND вызывает функцию nslookup(), для получения IP-адреса данного DNS-сервера. Функция nslookup() проверяет на правильность IP-адрес, если адрес неправильный (т.е. 0.0.0.0, 255.255.255.255 или мультикаст-адрес), вызывается функция nslookupComplain() для фиксирования данной ошибки в syslog'е.
Переполнение буфера происходит в функции nslookupCompalin(), при генерации сообщения о ошибке. nslookup-Compalin() использует sprintf() для создания строки, оканчивающейся машинным нулем — '\0'. Эта строка не должна превышать 999 байт и является локальной переменной. Если строка с именем хоста DNS превысит допустимую длину, то все что более 999 байт будет записано в стек nslookupCompalin(). В результате можно изменить адрес возврата из функции на адрес шелла, и — опаньки :).
Одно "но" — атакующий может использовать в запросе только те символы, которые используются в Интернет-именах, а из этого, согласитесь, создать адрес возврата нереально.
Солюшном в данном случае будет обновление BIND до версии 9.1.0.
ISC Bind 4: Некорректный формат строки в nslookupComplain()
Тип: удаленная.
Опубликована 29 января 2001.
Дополнена 29 января 2001.
Уязвимые продукты:
— ISC BIND 4.9.7-T1B, ISC BIND 4.9.7, ISC BIND 4.9.6, ISC BIND 4.9.5P1, ISC BIND 4.9.5, ISC BIND 4.9.4, ISC BIND 4.9.3, ISC BIND 4.9.
Неуязвимые продукты:
— ISC BIND 9.1, ISC BIND 9.0, ISC BIND 8.2.3.
Переполнение буфера происходит в функции nslookupCompalin() (что это за функция описано в предыдущей "дыре"), что позволяет атакующему преписывать случайные регионы памяти случайными значениями. Эта строка попадает в syslog() и содержит хитрый запрос (к примеру имя хоста) в качестве аргумента. В некоторых случаях hostname не указывается, и все это передается в *printf(), который используется в syslog().
Если атакующий подберет строку, то случайные регионы памяти будут перезаписаны. К примеру, атакующий может переписать адрес возврата из подпрограммы на адрес шелла. А в результате получить права рута.
Для реализации такой атаки вам потребуется собственный домен (в смысле зона ответственности DNS) и, по всей видимости, более чем один DNS-сервер.
Внимание! Атакующий может использовать в запросе только те символы, которые используются в Интернет-именах, а из этого, согласитесь, создать адрес возврата нереально.
В данном случае ICS рекомендует обновить ваш BIND до версии 9.1.0
DoS дыра в Netscape Enterprise Server при использовании
Web Publishing
Тип: локальная и удаленная.
Опубликована 25 января 2001.
Дополнена 25 января 2001.
Уязвимый продукт:
— Netscape Enterprise Server 3.0.
Netscape Enterprise Server — веб-сервер, который используется для крупномасштабных веб-сайтов. Web Publishing устанавливается по умолчанию. Данная директория доступна локальным и удаленным пользователям без какой-либо аутентификации.
Данная дыра функциональна, если работает Web Publishing. Если пользователь подключается к серверу и посылает команду 'REVLOG / HTTP/1.0', сервер падает. Эту команду необходимо повторить несколько раз, что бы достичь желаемого результата. Только перезапуск сервера возвращает его к нормальному функционированию.
Солюшном в данном случае будет отключить обработку REVLOG-запроса, а лучше — сам Web Publishing.
Дыра с обнаружением 'Index' в Netscape Enterprise Server
Тип: локальная и удаленная.
Опубликована 24 января 2001.
Дополнена 24 января 2001.
Уязвимые продукты:
— Netscape Enterprise Server 4.0, Netscape Enterprise Server 3.0
Снова возвращаемся к Web Publishing.
Netscape Enterprise Server со включенным Web Publishing позволяет показывать список каталогов на данном сервере. Если пользователь соединяется через telnet к серверу и посылает комманду 'INDEX / HTTP/1.0', то в результате выдается список каталогов.
Решение проблемы — отключение Web Publishing или обработки INDEX-запроса.
дыра в Wu-Ftpd — некорректный формат строки и мени хоста
Тип: локальная и удаленная.
Опубликована 23 января 2001.
Дополнена 25 января 2001.
Уязвимые продукты:
— Washington University wu-ftpd 2.6, 2.5, 2.4.2academ [BETA1-15], 2.4.2academ [BETA-18], 2.4.2 VR17, 2.4.2 VR16, 2.4.2 (beta 18) VR9, 2.4.2 (beta 18) VR8, 2.4.2 (beta 18) VR7, 2.4.2 (beta 18) VR6, 2.4.2 (beta 18) VR5, 2.4.2 (beta 18) VR4, 2.4.2 (beta 18) VR15, 2.4.2 (beta 18) VR14, 2.4.2 (beta 18) VR13, 2.4.2 (beta 18) VR12, 2.4.2 (beta 18) VR11, 2.4.2 (beta 18) VR10, wu-ftpd 2.4.1.
Wu-ftpd — широкоиспользуемый ftp-сервер для *NIX-систем.
Когда Wu-ftpd запущен в режиме отладки (т. е. запущен через inetd с опциями -d или -v), то возможна атака на данный сервер с возможностью использования некорректных строк. Когда Wu-ftpd находится в режиме отладки, он ведет лог команд пользователя через syslog() с меткой 'DEBUG'. При пассивной передаче файла, вызванной пользователем (реальным или анонимным), в лог записывается строка вида:
PASV port X assigned to HOSTNAME
Строка, содержащая данное сообщение, собирается перед вызовом syslog(). Значение HOSTNAME ресолвится сервером. Данная строка передается в syslog() как форматированная строка. В результате можно передать строку несоответствующего типа.
Также неизвестно в каких версиях Wu-ftpd режим отладки включен по умолчанию.
Ниже приведен пример эксплойта, демонстрирующего данную дыру.
$grep 127.0.0.1 /etc/hosts
127.0.0.1 %x%x%x%x%x%x%x%x%x%x
$ grep ftpd /etc/inetd.conf
ftp stream tcp nowait root /usr/sbin/tcpd /tmp/wuftpd-2.6.0/src/ftpd -v
$ ncftpget -F 127.0.0.1 /tmp /usr/lib/ld.so
$ tail /var/log/syslog.debug
Jan 24 14:17:01 xxx ftpd[30912]: PASV port 47479 assigned to 80862b0806487eb9778084da87bffff16c9640151020bfffe108401c9004 [127.0.0.1]
..<поскипано>..
По данному поводу Debian выпустила релиз и diff-файлы,которые исправляют данную дыру.
Washington University wu-ftpd 2.6:Debian upgrade 2.2 i386 wu-ftpd_2.6.0-5.2.1_i386.deb
http://security.debian.org/dists/stable/updates/main/binary-i386/wu-ftpd_2.6.0-5.2.1_i386.deb
уклонение от фильтрации пакетов в ipfw для FreeBSD
Тип: локальная и удаленная.
Опубликована 23 января 2001.
Дополнена 25 января 2001.
Уязвимые продукты:
— FreeBSD 4.2, FreeBSD 4.1.1, FreeBSD 4.1, FreeBSD 4.0 alpha, FreeBSD 4.0, FreeBSD 3.5.1, FreeBSD 3.5, FreeBSD 3.4, FreeBSD 3.3, FreeBSD 3.1, FreeBSD 3.0.
Неуязвимый продукт:
— FreeBSD 5.0.
FreeBSD, как и множество других современных систем, имеет подсистему фильтрации пакетов, встроенную в ядро. Дыра в данной системе позволяет атакующему проскакивать через правила фильтрации. Это связано с интерпретацией флага ECE в заголовке TCP-пакета. ECE-флаг — эксперементальное расширение TCP и часть резервных опций TCP.
Когда фильтр пакетов анализирует TCP-пакет, имеющий установленный ECE-флаг, он интерпретирует его как часть уже установленного TCP-соединения и пропускает его.
Атакующий, использующий данную дыру может перехитрить файрвольные правила. Пакеты, сконструированные с установленным ECE-флагом, проходят через файрвол.
Эксплойт выполняющий эти действия представлен Plathond <jacques4i@yahoo. com>и находится по адресу:
http:/securityfocus.com/data/vulnerabilities/exploits/ecepass.tgz
По данному поводу FreeBSD выпустила ряд патчей:
FreeBSD 4.2: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 4.1.1: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 4.1: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 4.0: FreeBSD patch 4.x ipfw-4.x
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch
FreeBSD 3.5.1: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.5: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.4: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.3: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.1: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
FreeBSD 3.0: FreeBSD patch 3.x ipfw-3.x.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch
Ghost//Necrosoft
Сетевые решения. Статья была опубликована в номере 02 за 2001 год в рубрике save ass…
